Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We saved $50k/year with a Go microservice coded in a hackathon

movio.co

Post reply on HN
Print view View original

231–240 of 264 posts

Re: We saved $50k/year with a Go microservice coded in a hackathon

#231

Post by softawre »

owenmarshall wrote: post #9
wasd wrote: post #3

Great story, thanks for sharing. I wanted to ask a quick question about something: > Refreshing caches automatically How do people usually handle this? Is this something done on the application layer or database layer? Where is the cache stored?

Caches could be stored in the database in a materialized view, in an external service like memcache or redis, or even in the application itself. Expiry can take a few different forms. Some caches have a defined space and use a replacement scheme like "fill the cache up, then remove the least recently accessed value". Some don't have defined sizes but instead remove entries based on timestamps (cache for n minutes). S…

Good response. We mostly use redis as a LRU cache and it works great.

https://redis.io/topics/lru-cache

Re: We saved $50k/year with a Go microservice coded in a hackathon

#232

Post by slx26 »

foepys wrote: post #192
slx26 wrote: post #184

Earlier quoted context omitted.

To be fair, we used to die at 40. Now you can get a CS degree at 21 or 22, and you still "have no idea what are you doing". Maybe it's just that technology is really complicated, the world is really complicated, and everything is changing fast. I don't mean it to be conformist, but it's easy to forget some things are actually hard when you are very clever or old enough to forget how it was like when you were still le…

But at the same time it's easier than ever to find information on nearly everything. Asking experts also is easier than ever before. I don't think it's feasible to dismiss GP's claim with yours.

Sorry if it came across like that. Not trying to dismiss his claim, just trying to give a wider perspective. Similarly, in the same way you are right saying it's easier to find information on nearly everything nowadays, it might also be relevant to remember that we still have limited time and attention spans.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#233

Post by vram22 »

smoe wrote: post #205
attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

I think it is not necessarily the age but the mindset of focusing on solutions instead of understanding the problem first. It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... I…

Right. That second paragraph of yours, i.e.:

>It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ...

is absolutely real, I've actually seen in happen both in projects I was in, and heard or read about.

This Rich Hickey video is somewhat relevant, IMO:

Tech Video: Rich Hickey: Hammock-Driven Development:

https://jugad2.blogspot.in/2016/03/tech-video-rich-hickey-ha...

You have to watch it at least part way through to get some of the better points in it, although the whole thing is good.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#234

Post by zeveb »

otterley wrote: post #227
dijit wrote: post #180

Earlier quoted context omitted.

To be perfectly fair with you, you can make bad choices and still get something useful done. Most companies are not alive "because they chose mysql over something else" they're alive because they have "good enough" tech to get the job done. The job that they're trying to accomplish is the thing that makes them successful. Uber isn't super huge because it used a specific database technology. It's huge because it's goo…

If it got the work done at a reasonable cost and performed reasonably well (i.e. it served the purpose it was meant to serve), how “bad” a choice could it have been?

I'm reminded of an article about zombie companies I read recently: they're companies which are inefficient/pporly-managed/poorly-executing, but due to market/regulatory inefficiencies they're not dead yet. Companies which use MySQL are in a similar situation: they're not doing as well as they could be, and all other things being equal they ought to be put out of business by their competitors — but all other things are rarely equal.

Still, if you are making choices for yourself, you don't choose mediocrity and hope to muddle through: you choose excellence. Choosing MySQL isn't choosing excellence.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#235

Post by smoe »

vram22 wrote: post #233
smoe wrote: post #205

Earlier quoted context omitted.

I think it is not necessarily the age but the mindset of focusing on solutions instead of understanding the problem first. It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... I…

Right. That second paragraph of yours, i.e.: >It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... is absolutely real, I've actually seen in happen both in projects I was in, an…

Yeah, my opinions on this are "slightly" influences by the Rich Hickey talks "simple made easy" and "hammock driven development":)

The difficulty I find is, identifying the moment to leave the hammock again in a startup enviroment. To what degree do you need to understand a problem before you take action. If you try to understand it 100%, you'll never get anything out there.

But I'm already very happy that I was able to convince the business side of the company of the approach in a brief talk about it and they now referrer to "the hammock" themselves :)

Re: We saved $50k/year with a Go microservice coded in a hackathon

#236

Post by vram22 »

smoe wrote: post #235
vram22 wrote: post #233

Earlier quoted context omitted.

Right. That second paragraph of yours, i.e.: >It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... is absolutely real, I've actually seen in happen both in projects I was in, an…

Yeah, my opinions on this are "slightly" influences by the Rich Hickey talks "simple made easy" and "hammock driven development":) The difficulty I find is, identifying the moment to leave the hammock again in a startup enviroment. To what degree do you need to understand a problem before you take action. If you try to understand it 100%, you'll never get anything out there. But I'm already very happy that I was able…

>The difficulty I find is, identifying the moment to leave the hammock again in a startup enviroment. To what degree do you need to understand a problem before you take action. If you try to understand it 100%, you'll never get anything out there.

Agreed. The problem, though, (and I'm painting with a broad brush here) is that the erring tends to be much more on the side of not trying to understand much or at all, of the problem, before jumping into action. I think a lot of it is due to peer pressure and wanting to be "seen" by peers and bosses (and VCs) to be doing stuff, as opposed to really getting things done better in the medium term, even if in the short term it looks like you are not acting but "only" thinking or analyzing or designing stuff. Hence my comment in that post I linked to, about "we have to ship next week". All too common - been there, seen a good amount of that. In fact, this subthread between HN user jacquesm and me just recently, is basically about the same point, although described in different words:

https://news.ycombinator.com/item?id=16774234

>But I'm already very happy that I was able to convince the business side of the company of the approach in a brief talk about it and they now referrer to "the hammock" themselves :)

Cool :)

Re: We saved $50k/year with a Go microservice coded in a hackathon

#237

Post by otterley »

dijit wrote: post #230
otterley wrote: post #227

Earlier quoted context omitted.

If it got the work done at a reasonable cost and performed reasonably well (i.e. it served the purpose it was meant to serve), how “bad” a choice could it have been?

If it costs development time because they need to be extra careful about not sending queries that ERROR and 'wipe' data. If it silently corrupts data over years and gets discovered much later. (As was the case with my previous company, an e-commerce retailer that lost large chunks of order history)

Are those problems still unresolved in MySQL today? How do you know that similar or worse problems did not exist in alternative solutions at the time it was implemented?

Re: We saved $50k/year with a Go microservice coded in a hackathon

#238

Post by otterley »

zeveb wrote: post #234
otterley wrote: post #227

Earlier quoted context omitted.

If it got the work done at a reasonable cost and performed reasonably well (i.e. it served the purpose it was meant to serve), how “bad” a choice could it have been?

I'm reminded of an article about zombie companies I read recently: they're companies which are inefficient/pporly-managed/poorly-executing, but due to market/regulatory inefficiencies they're not dead yet . Companies which use MySQL are in a similar situation: they're not doing as well as they could be, and all other things being equal they ought to be put out of business by their competitors — but all other things a…

“Excellence” is a poor criterion for comparative analysis because it is (a) subjective and (b) unquantifiable.

Do you have objective or quantifiable data and references upon which your opinion is based, _and_ is universally applicable to any arbitrary problem that a SQL database might be an appropriate solution for?

Re: We saved $50k/year with a Go microservice coded in a hackathon

#239

Post by tetha »

smoe wrote: post #205
attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

I think it is not necessarily the age but the mindset of focusing on solutions instead of understanding the problem first. It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... I…

I think with experience, "easy" changes.

Some time ago, I thought it was to write code to do things. By now, I mostly ponder how I put things into postgres/kafka|rabbitmq|../memcache|redis|.../elasticsearch/neo4j so I can reduce everything to good queries into these systems.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#240

Post by e12e »

dijit wrote: post #229
Thaxll wrote: post #210

Earlier quoted context omitted.

All this list is fud. You should provide examples to those claims because right now you sound like someone that never use MySQL.

I appreciate that it might sound like that to someone who hasn't used MySQL in production for 10+ years. To start with, this is still true today: https://vimeo.com/43536445 Despite being 6 years old, strict mode is still required. Anything prior to MySQL 5.7 will accept "0000-00-00 00:00:00" as a valid date, 5.7 will not (which is sane) however this means migrating from 5.6 -> 5.7 just got a little harder. In fact it…

> will accept "0000-00-00 00:00:00"

Isn't it? I thought that today()-(2018 years, 4 months and 10 days) would be approximately that date? Maybe you prefer +0000 vs just 0000?

'ISO 8601 prescribes, as a minimum, a four-digit year [YYYY] to avoid the year 2000 problem. It therefore represents years from 0000 to 9999, year 0000 being equal to 1 BC and all others AD. However, years prior to 1583 are not automatically allowed by the standard. Instead "values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange."

To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[19] An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[20] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.'

https://en.m.wikipedia.org/wiki/ISO_8601

Now, if mysql accept, but can't store such a date, I understand that it's a problem.

Post reply on HN