nhumrich

47 ms·

601.
by nhumrich 10y ago
Exactly, resolving ambiguity is the main thing I look for in interviews. It's actually a very important skill. Business requirements are often ambiguous and I need someone who can ask questions to make the more clear.
602.
by nhumrich 10y ago
This guide talks about batch get which is www.example.com/foos/123/bars:batchGet You could do something similar for other batches
603.
by nhumrich 10y ago
No, it doesn't mean you suck. But it does mean that those with full GitHub profiles usually spend every waking our programming. If they have e that much passion and programming hours under their belt, and you can see their code example
604.
by nhumrich 10y ago
Thank you! I never realized I could do this for some reason. I always restored from snapshots.
605.
by nhumrich 10y ago
I mean, it's still a manager decision. So it usually goes green-i after you notice the issue. I would say it's the same, still not very reliable. But do know, that if you see the I indicator, something is wrong
606.
by nhumrich 10y ago
I know about the daily snapshots, but didn't know about the archive logs. Is this something I have to enable? How do I get the logs and how do I restore using them?
607.
by nhumrich 10y ago
not really. But the manager IS held responsible if they go green-i too often. As sometimes having a bad status can trigger AWS to give credits back to certain customers.
608.
by nhumrich 10y ago
I have worked at amazon, and I can validate this. When I was on an AWS team, posting a "non-green" status to the status page was actually a Manager decision. That means that it is in no way real time, and its possible the status m
609.
by nhumrich 10y ago
If you don't think the JVM is heavy try running it on a t2.micro. It can never get enough memory to start. I haven't ran in to any other language runtime that won't run on a t2.micro
610.
by nhumrich 10y ago
I switched to colemak a year ago. Best thing I've ever done. The first month was REALLY hard. But I got over the slump and now I'm very grateful I did it. Typing is so much more natural feeling now. All the stretching in qwerty is
611.
by nhumrich 10y ago
Yes, because the real bottleneck is TCP. Pipelining reduces number of packets sent. However, very few clients actually support pipelining, so it's almost useless
612.
by nhumrich 10y ago
All you have to do is enter an email address. It doesn't even have to be a real email.
613.
by nhumrich 10y ago
I would say for backend you can get away without feature flags most of the time. But for the frontend, it's almost impossible to ship a new incomplete feature without feature flags
614.
by nhumrich 10y ago
Why not? Loads of companies do this. Almost all the big ones I know of do this.
615.
by nhumrich 10y ago
According to the article, and my personal experience, you don't commit directly to trunk. Trunk based means that you don't "collaborate" on a branch. So you write your code based off of trunk, once it's ready you co
616.
by nhumrich 10y ago
I'm kind of lost by your comment. > Write tests first What does this have to do with TBD vs branch based? Should be that way either way. In fact TBD breaks down if you don't write your tests. > A branch doesn't move to
617.
by nhumrich 10y ago
On a big team, potentially 100's. But if your delivering all commits regardless of branches, why even have branches?
618.
by nhumrich 10y ago
Yes, rebase early and often works great. But if your branch includes a major refactor, your going to find yourself editing others code to get your rebase to work. That just increases your own scope. But yes, rebase often is often a very via
619.
by nhumrich 10y ago
My point is that the article says that branches for the purpose of WIP and code review is OK as long as you don't share the branches. Trunk based is trunk "based" as in your git "base". Your based on trunk, not a br
620.
by nhumrich 10y ago
I would say the bigger the repo becomes (in terms of # of collaborators) the more important trunk based becomes regardless of SCM choice. Mainly because merging many branches for many teams becomes very tedious and hairy. By the time you re
621.
by nhumrich 10y ago
The gain is early integration. If you have more than one branch going on at the same time, they can diverge quite significantly, and merging can cause bugs, or sometimes more work. If you only ever have one feature branch at a time, you mig
622.
by nhumrich 10y ago
By "short lived", how short lived? Is the branch only for one developer? Or is it shared? How do you enforce "short lived"? If the branches are not collaborated on, you might be doing trunk based without realizing it.
623.
by nhumrich 10y ago
So your delivering all commits on all branches to prod? That sounds hairy
624.
by nhumrich 10y ago
Who are your two poster children? Because in my mind it's Amazon and Google, who both use git
625.
by nhumrich 10y ago
You must not understand what CD really means then, because full CD is impossible with feature branches. CD means every commit gets built and delivered all the way prod if it passes all tests. The key word is "continuous" as in, e
626.
by nhumrich 10y ago
Then give it a stupid name. "helper_func", "inline()", or even "_a". If you think the name isn't important, then don't waste your time on it.
627.
by nhumrich 10y ago
While I applaud Google for doing this, it's also very scary that Google has that much power that they can basically make anyone on the web do anything by threatening ranking blackmail. Google is starting to use more grey area tactics
628.
by nhumrich 10y ago
I would try out rancher. It's kinda like kubernetes but uses docker lingo. Kubernetes has a somewhat high learning curve (what's a replication controller? Why is that different from a pod?). Rancher will even spin up new hosts fo
629.
by nhumrich 10y ago
I felt like the CD = continuous delivery was obvious. But perhaps I've spent to much time on Dev Ops. Maybe simply saying CI/CD would be sufficient.
630.
by nhumrich 10y ago
Very true. I had a phone with a physical slide out keyboard up until they didn't make them anymore. Moving to a touch screen keyboard was and is still difficult, and I make typos all the time.

More ›