To me it sounded very much like Limburgs dialect (specifically Kerkraads dialect) "adieë wa" (only first part, but sometimes the second part is omitted anyway) [1]
English Wikipedia also has an entry for the company Adyen, btw [2].
Yeah, we also use something like this for building a website/webapp (for a client) with 5-10 people.
- Feature branch: do whatever you want
- Develop: should be good enough for the client (product owner) to look at
- Release branch: should be good enough to be tested by the test/QA team
- Master: should be good enough for website visitors
Branches are meant to be shortlived and merged (and code reviewed) into develop as soon as possible. We use feature toggles to turn off functionalities that end up in develop but can not go to production.
The problem with having too many eternal branches is that they quickly become unmergeable. The nice thing about feature branches is that it's the author's responsibility to make it mergeable. But if you having a bunch of eternal branches none of which are "owned" by one person, when it comes time to merge them and there's dozens of merge conflicts there's not one person that can set down and know what the correct fix is for all of them.
I think the idea is that the branches cascade. You would never create new commits directly into release or master, the flow would only ever be develop > release > master, thus making merge commits and conflicts impossible.
That's exactly what hotfixes are for. A completed hotfix will merge directly into develop and master simultaneously (practically speaking). This allows you to keep your unrelated develop commits out of the master until you're ready to merge it all.
For a long time I have a fascination for improving memory. It seems that visualization and memory are closely related, or even one and the same. Tony Buzan and Joshua Foer are authors that have written about this.
They write about techniques to learn a deck (or decks) of playing cards, names of people, long numbers, etc. The 'roman room' is one of these techniques, that is used for long speeches; and was also used by people like Seneca. See here a clip of how it works to learn a deck of cards: http://www.youtube.com/watch?v=X-xl7_hdWZo
The essence of these techniques is that you must create the most vibrant or bizarre imagery in your head about the subject. Not only visually, but by using all the senses: smell, taste, etc.
Da Vinci is also known for training his visualization skills by looking at an object for a moment and then trying to draw it from memory. I believe that is from Michael J. Gelb's book 'How to think like Leonardo'. (Which might not be the best source.)
For how consciousness and how we see things works this video by Susan Blackmore might be interesting, because it discusses with how much (or less) detail we can see with our eyes open in the first place: http://www.youtube.com/watch?v=sdMA8RVu1sk (from 40:00 or so)
I think inline comments are fine for when you are doing something really weird (for, say, performance reasons) that needs explanation, but if you want to document the why of the entire codebase, I feel the test suite is a better place for that.
Not only can you explain the why and demonstrate usage in a logical manner, but you get some consistency checks from your documentation for free.
I wish more projects would document the more "macro" knowledge about their code - the infrastructure and organisation, for instance, or the metaphors used throughout the code.
The problem is that the implementation of the 'why' can be scattered over many files, classes, functions, etc. So where to put the comments?
You put them everywhere that might be relevant, along with cross-references to other relevant code/documentation. Humans aren't robots -- redundancy is a good thing, because it helps our feeble minds more quickly reinforce key concepts.
The first thing to know about comments is that they're sooner or later going to get out of touch with the code, unless you have some phase where you are going to review them in depth.
Obviously, redundant comments scattered across the code are even worse: out of sight, out of mind.
That's the oldest, tiredest objection to commenting that you could possibly write. It's the first objection raised by every wet-behind-the-ears, new-grad coder. It's a cliche. It's also crap. Yes, unmaintained comments will go out of date. That's why you maintain them, just like you maintain your code. And don't argue that it's too hard -- writing code is harder, and you do that all day long.
Your first job as a professional programmer is making the rest of your team more productive by reducing the communication burden. Your second job is understanding old code. The amount of code you personally write is a distant third priority.
Funny you should say that, considering the number of experienced coders who have a different opinion. I'm not arguing for no comments at all (especially regarding non-obvious things), but most of your code should be self-documenting, assuming sufficient domain-level knowledge from the reader. If it's self-documenting, comments are redundant.
"most of your code should be self-documenting, assuming sufficient domain-level knowledge from the reader. If it's self-documenting, comments are redundant."
You're hitting on all the classic lame excuses. Self-documenting code is a myth, invented by lazy coders who would rather crank out code than write documentation, because it's more fun to write code. They're wrong, but they often don't know that they're wrong, because the same people who suck at writing documentation usually suck at reading code.
Clean code is a necessary, but insufficient precondition to understandability. Documentation is essential, because code can only tell you what -- it can't tell you where it should be used, why you should use it, how it should be used, who who should use it or when it's appropriate. And in any case, your code is never as clean or self-documenting as you think it is.
That said, I have no doubt that you're hearing these things from "experienced" coders, because our industry is filled with "experienced" people who suck at what they do. Also, these things are cliches for a reason. They get repeated a lot.
You can obviously get away with not documenting code, but you don't know what it's costing you. However well things are working out now, I can guarantee that they'd be working better and faster for your team if you spent the time to write good documentation.
You may think Martin Fowler is one of these "experienced people who suck at what they do", but you're likely to find yourself part of a small minority.
going to get out of touch with the code, unless you have some phase where you are going to review them in depth
I think treating comments as something that's done in a separate phase is the wrong mindset. Comments should be integral part of code and therefore change whenever the relevant code changes.
Maybe, but it's not that easy. You're generally going to see a 3-lines-of-context diff, and the reviewer won't necessarily have the idea to read the entire file (or worse, go poking elsewhere in the codebase) to see if comments deserve changing.
Well, that's an overarching why. But why you're doing this one specific thing on this line, which might look wrong or overly complex or just bizarre... you need to comment those.
// foo library throws an extra two bytes at the front of the
// array, even though that isn't up to spec, so we have to
// strip them out here.
It's a fair point, though. The href attribute tends be very long, so if your criteria is readability, do you opt for attribute soup or put it in a wrapper div or span? It's a subjective decision, and I don't think there's a right or wrong answer, but examples should reflect real world situations.
Either way, I think href should be a universal attribute (obviously, it wouldn't make sense on something like br). It offers a lot of flexibility and is probably no more subject to abuse than anything else. I don't see how browsers would have a problem implementing it. Just look at the 3D view of a complex page in the Firefox Inspector to get an idea of what they're already coping with.
I assure you that every useful implementation of an HTML Parser--apart from validation tools--will handle the missing alt just fine, regardless of what the spec says.
It's not about being "ugly" and needing help to become "beautiful". It's what you are trying to tell people.
Partly, it's a good thing if these sites look a bit amateurish, because they should look grassroots. It should look like: wow, I can join this. It should look authentic.
A nice example of this is www.drupal.org (where you can join) versus www.drupal.com (where you should "buy").
The new Git website is very nice. But is also a very mature project. It doesn't need help from thousands of people. It needs a lot of consumers and maybe some brilliant minds to share their
ideas.
What the Go website tells: this is a very young project (not even a logo), we have some backing from Google (hence the name and the colours), we have something good (by calling it "easy" and "reliable"), but we could need your help (by still calling it "The Project") and you might want to try (look you can even try it top-left on our homepage) this if you are curious and want to have fun (see our goofy, eye-rolling, mascot).
