spotman

Why everyone 'seems' to 'love' it the same reason functional programming and postgres are darling technologies here on HN.

It's more culture than anything else. People have been testing code for years and years, and people will keep making ways to organize teams, workflows, and every half decade a new Bootcamp, Redmine, Asana and Jira will come out.

At the end of the day, you have to have something in place. The bigger your team is the more you need it.

TDD is simply one school of thought for how to ship less bugs.

Some people do it, most people do not do it strictly.

Most of the teams I work with this day and age are no longer very strict on TDD because for their specific products they are shipping it slowed down development enough to notice.

But some people love it and some people I think it may make faster.

Personally I look at it as a way to solve a problem, likely when assembling a new team. If you don't have issues with speed and quality and coordination then I wouldn't try to add TDD. But if you do it's one of a handful of potential solutions , and depending on your team and product may or may not be a solution.

A friend still uses my original iPhone, with edge.

He got it off me for cheap back in the day when I upgraded,but now he keeps it going as a fashion statement. Amazing that it still works !

You will need to break out your sales skills and tap the network you just mentioned.

On paper, having built stuff for YC startups sounds like you are plugged into an amazing network. So it is a balance of being direct "hey we are taking on new clients!", and a balance of going to events and being more indirect and observant.

Go to events, go to trade shows, be social, make yourself known, write blog articles under the name of your group that they can find you under, and if you can manage it publish some open source code.

All of this sounds way easier and like less time investment than it really is sadly, but it will build your reputation.

But in summary, the consulting gig requires a healthy portion of creative sales skills and other skills, so have fun practicing them all in addition to tech skills.

good luck!

Yea sure some people in the sea of 500 will be doing elegant clean things, working in the core part of the business ( usually at or near the cash register program ) but if you have reason to have 500 developers you don't simply get the luxury of having every project be written perfectly.

Landing somewhere in-between by getting things done not perfect but shippable, and doing it fast as possible is par for the course ime. The best code is always written the 2nd or 3rd time, never the first.

Especially on the case of hyper growth worrying your competitors like lyft or postmates or amazon might get something pivotal out first.

People have to learn somewhere, usually things like this they learn at scale, on the job.

Not really, YouTube runs on MySQL. Pretty sure it's still the largest video site in the world.

Sure, but the show must go on.

Your absolutely correct that it is not risk free, however, if you do not use foreign keys (which no huge scale mysql install like schemaless does) and you know what your doing (read: calculating the expected load, adding throttles and sanity checks, backups, etc) online alters are extremely feasible with mysql and folks have been doing them for years.

I know first hand shops like FB use a similar method in production.

Also, big note, the whole point of "schemaless" (And other things, like fb's friend feed architecture) is that you don't make schema changes.

Try enforcing this on teams that use ORMs like hibernate with 500 developers.

Super, duper, common issue, you will find this at every large shop at some point in its life time, usually around the time of hiring people and expanding extremely fast, and taking on some tech debt.

All functions of extreme scale, hyper growth, and yeah, not following the absolute best practices all the time, but tech debt is like any debt, you get something now, and pay later. If they continue going up and to the right they will be able to afford it.

> I have to very seriously disagree here, ORMs

In spirit I agree with you, its the engineer's fault for not reading the documentation of their ORM or equivalent.

But in these big ships with hundreds of programmers, leaving transactions open in hibernate is a daily occurrence somewhere.

Usually caught before production, but happens oh-so-frequently, that anything that exacerbates the pain from this would be seen in a negative light for sure.

Like uber pool, vs uber normal vs uber premium. Just have to get rid of the pesky drivers.

Cool idea!

Random Feedback:

- Made it through the survey, was expecting to create a password before you asked for money, so upon closing this window, I just realized that I am not sure if I have an account. On a hunch I re-entered my email and you did save my info so all was not lost, but had a moment of 'oh I'm just going to give up then!' Possibly make it obvious that you can return later, and possibly make it obvious you don't actually want a credit card today.

- The survey feels like more work than just browsing instacart. I get that your trying to really understand me, and I do think thats brilliant. I get that this is an investment into me saving time in the future, but after completing the form the meals that were offered to me do seem quite random. So this leaves me with the feeling that this service is going to take some trial and error and work on my part to get into sync with me.

- Possibly since I am not a picky eater with dietary restrictions, then I am leaving you too much wiggle room to read my mind. Therein, possibly this service would just move my innate ability to be indecisive about what I want to eat to you. If this is the case, then I don't know if I want to pay 10 bucks a month to continue to be indecisive.

- In making it all the way through to the "buy on instacart" page, I end up on instacarts site with an empty shopping basket. Not sure if that is intentional, but if that is a limitation then there is no way I am going to pay because that is where the lions share of time savings for me would come from, easily inputting stuff into instacart.

I will probably try to give your service a proper test and order some of the recommended recipes. I think if it really gets to the place where its with-out-a-doubt saving me time, and ultimately managing the food intake of my entire household, I would spend the 10 bucks for it, and if it does that without me even needing to intervene I would spend 15-20.

The product seems extremely sophisticated for an initial product offering. Wonder if there is a way you can focus on making the initial impression accomplish a smaller task first (like, "plan for perfect date night at home!") where the scope would be reduced to helping someone get 1 meal you design, near effortless, from instacart, surrounding dietary restrictions, rather than overwhelming users with wanting to deep dive into trying to digitize their kitchen 20 minutes into the product.

Keep hacking on it, could see this being powerful for busy people.

Would that lead you to write an article that said 'goodbye android forever' and tell people to avoid it because you prefer iOS?

That's the kind of 'taking sides' I was intending to articulate.

Well said.

I feel the same way about this as I do platforms. There is amazing projects on every platform. There is horrendous projects on every platform.

Taking sides just a narrows your point of view and lessens the amount you can learn.

The difference between a consultant with lots of real world experience and not.

Yes there is slippage, but you learn to plan for it. In the past week I had an employee have a baby and an employee have a parent pass away and another one have a horrible knee injury and be unable to work for a couple days, meanwhile we lost no time on a project by we are up some of our buffer.

If you don't plan to meet your deadlines even when faced with feature and scope creep ( which managing is another discussion entirely ) or things 100% out of your control there is other people that can and so your not going to be picked for projects that require real time mission critical demands.

And yea, if you figure that out, you get to charge more, and sleep less.

Maybe an unpopular opinion here, but I agree with the article overall.

My view is less that programming is going away, and more that all jobs are. Not immediately or anything, but I don't think we are going to magically produce programming jobs for all the masses who are going to need a job.

Having been at this over 15 years I have single handedly automated thousands of jobs, and of those a healthy handful are making things more efficient that a project needs less programmers, etc..

So while we will still need programmers probably forever , I'm not sure why people think that the number of programming jobs will do anything but stay the same or decrease, while the number of candidates increases.

Tooling has come so far, and it's going to go farther. You don't need to know a lot to make something meaningful anymore.

How we expect to train all children to be programmers and think that by the time they are our age it will still be a field that is lucrative is silly I think. My prediction is with all the new programmers coming into the field intersecting with the tooling getting better, intersecting with that a lot of other markets need less people I think we are left with a crowded field of players where the average skill level is lower because the tasks do not require it to be all that high any more.

Programming is the new carpentry. Probably jobs for a long time , but training the children now like it's going to be the most amazing career path is short sighted I think.

Considering this, I hope my kids don't pick programming as a career. I would love to be wrong.

Have a ton more experience with aws, but one large project has moved to GCE recently and everyone involved is beyond pleased.

The tooling and features are almost on par, and the ux is just better. Things like more powerful configuration of load balancing puts GCE over the top.

Considering how much cheaper GCE is for many projects aws is losing its appeal without some price breaks.

Also GCE is faster to launch instances by a measurable margin.

Would have liked to see some real cost analysis, other than it should save you money, because that is only true if scale is small to medium.

That's the thing, I guess the demographic that lambada is going for it will save money, but along with the mentioned vendor lock in, when you really need to have something on and processing requests non stop the costs savings really evaporate.

It's weird to me that the serverless thing catches on when it seems to be best suited for projects in their infancy without need for 24/7 request processing , or things out of the critical path like image resizing or things of this nature. But entire apps? Feels very much like going back in time to shared hosting.

I could see it saving money until about 1m requests a day and then a sharp drop off where you are hemorrhaging cash after that...

With modern auto scaling systems that aws and gce provide I bet most shops don't stand to save any more money than with a normal modern day refactor.

At the end of the day this leaves you more rope to hang yourself with. It makes it easier to run slow or poorly thought out code. 1000 processes might be cool but is never as cheap as 2 working correctly that accomplish the same thing, as an extreme but actual example of a situation I helped unwind with GAE, which was serverless before the buzzword.

You are approaching it too much like a programmer in my humble opinion.

Yes there is rules and guidelines, but before you can follow them you need a style , a feel , a culture .

You should get ( pay ) a graphic designer friend to come up with some food mockup of a single page. Work on it worth them or have them do a few iterations until you are really excited about it and both of you think "aha!"

Once you get that far your next challenge is to truly use this as a style guide and pivot off of it as you design the rest of the pages.

Good luck, it can be rewarding!

Depends how hard you try, but don't let reading stop you!

My greatest mentor was mostly blind. He could see the terminal but would need to be about 2-4 inches away and would be energetically moving his head as he read the contents of the screen.

Maybe they should consider different marketing semantics than "autopilot".

I guess "partial driving assistant" doesn't sound as good, but might be a better term.

Good idea; bad execution.

It's an expensive to question to answer whether they are worth a second shot at this point.

My money is on no, the brand is tarnished, but some day the idea seems like it will resurface, and when it does whoever shows some more evidence of real technology will be quickly funded.

Redmine and gitlab are usually where I reach when jira makes me sad. Redmine has more elaborate workflow possibilities, but gitlab is more light and simple. I actually use all 3 every day depending on what project I am working in.

Tldr, we were worried about running out of disk space, and setting up distributed logging is hard. So we decided to shoe horn our JavaScript app into lambada and justified it because some thought was put into how much effort it would be to undo this one day.

The author also touches on price and at their scale is saving money, and recognizes that one point will come where it's actually more expensive, but doesn't want to care about that because "infinite scale" is too cool.

From the article: > While there is certainly an argument for calculating the exact point at which EC2 vs API Gateway and Lambda is more cost effective, we believe that the latter’s ability to scale “infinitely” almost immediately makes it worthwhile.

The takeaway here is that if you don't have time for operations and you don't have a lot of traffic you can pay someone else to worry about this.

Finally one of the reasons the author lists is that they don't want to have to setup logging ( which is hard to get right, I get it ) but at the end of the article they admit they use another service/plugin for it and that it's not that great.

Careful, when you get to the scale that this stuff is not cheaper is also about the point where you need to understand all the gory details of distributed logging, or you could use splunk, but now you really aren't saving money.

Seems like something like a periodic task that is not your main business ( read: needs to run 24/7 ) might be a better fit than cramming your entire app into this architecture simply because your background workers are not busy enough yet to justify being on 24/7.

Having said all that, the rest of the points touch on refactoring their app so that much of it can run from an s3 bucket, and this in my opinion was best part of the article as its good advice for anyone that wants to have things fronted by a cdn.

At any rate, good luck with the entirely serverless architecture. Parts of it are cool, parts of it are a recipe for save time and money now and pay for those decisions later , and managing this is just another form of technical debt, sometimes is worth it, but can be dangerous when seen as a silver bullet.

In the car business though, it's a pre-requisite to paying the bills, and a positive step along a complicated path to getting them paid.

This is fantastic! Thanks for sharing. It could be because I have not looked hard enough but this type of knowledge is not easily findable all in one place.

Great job at striking a good balance between opinion and best practice, I already came away with a few ways to optimize some parts of a large Es cluster I manage.

I don't think the parent comment is talking about the UX really.

But on the topic of UX and what are or are not losing, I will say that the UX of slack is not so good when it eats 2gb of memory all day and beachballs a modern day iMac quite badly if you have a channel with lots of fancy formatting.

I have written to slack about this and they wrote a polite response back acknowledging the issue. Really hope they do solve this soon (Despite the connectivity issues) because it's become unusable for my team lately. Supposedly according to slack it is compounded when you have multiple teams.

We have a team per client as we primarily do consulting, so now we have had to switch some teams over to another solution so that we can allow the teams that must be in slack to stay in slack.

So, while I think slack has the potential to be much better in every single way, days like today illustrate that it's an SPOF, and on days when it is available, I would not call the experience reliably good, not as reliably good as modern day IRC is, unfortunately. (and I don't say this lightly, i love things like in-line code blocks, @ notifying people, mobile clients, and more)

This is a tough one. It's easy to be the expert and point out what will not work.

The crux of it is as he states the false advertising, and how many people will see this and start to use it without knowing what they are doing. However it's hard to separate false advertising, with overconfidence. Maybe they even do not have to be the different things in this context.

The author is correct, this is incredibly hard to get right. Without having some experts heavily contributing and steering a project like this (and, by experts, I mean distributed filesystem experts, not just general distributed application knowledge) it is going to be a long uphill battle, fraught with terror.

But, who's to say that they won't find that type of collaboration. They may just do that, and they may just pull off making a decent project in some years.

But is it hard, hell yes. Is it going to happen as fast as they claim, probably not. Is it a silly idea to build this and not contribute to prior art more? Probably. Is someone a little pissed off about this and taking to the internet to moan about it a bit? Probably.

At the end of the day, file systems are hard, and if your job is to deploy, manage, scale, or recover them, you won't just be blindly throwing your petabytes at a brand new project anyways, and if you are, you should be removed from your current position.

The type of folks that will be early adopters and contributors won't be putting their banking transactions on it.

So if you have an ASG of 4 nodes and one goes down, how do you know that the traffic will land on the right node? What if that node is really busy? When the new machine comes up automatically does the system migrate queue ownership to it? Is there a time when the system can be partially unavailable?

Possibly most importantly would be, how are you routing queues to hosts and how is the platform load balanced. Using ELB and a tcp listener is a great way to throw away performance with clustered rabbit, not to mention adding a ceiling as to how wide the cluster can get.

Looks like a helpful project.

Having said that the clustering is often not the hard part with rabbit, well configuring it at least.

The more difficult issues are keeping it clustered amidst your typical day of network hiccups in cloud environments, as rabbit can be sensitive, preventing mnesia from going out to lunch, and as far as scaling goes certainly it can't go without mention proper planning, including queue HA strategies and ownership.

Since rabbit doesn't just scale each queue across all boxes in a way that distributes load, a smart team will use several queues carefully plotted onto specific hosts that own each queue and carefully replicate that to a small number of other rabbits but certainly not more than a small amount of other hosts and never the whole cluster.

For these reasons I have to think that this would be a nice addiction to aid in setting up clusters and maintaining a fleet size, actually scaling and operating a high volume rabbit cluster this would only be a small tool in the toolbox however.

Without knowing the whole picture of what kind of workload birthed this approach it makes me nervous to think rabbit would be managed by autoscale, prone to its deciding it wants to replace pieces of the cluster at any time, different high volume queues landing on different hosts, mnesia deciding it doesn't want to play ball anymore etc..

Possibly it's for very volatile workloads, none of the queues are HA, and this plugin forcefully does a hard reset of rabbit to recluster it when something goes awry?

Sometimes though, the scale of these things is enough to make programming (and operations if your into that) completely exhilarating.

Things that seem extremely trivial, like chat, or the ability to upload photos, become quite an engineering feet when your measuring the amount of photos uploaded at terabytes per hour or more.