Regex can be painful in cases which go beyond the low-lying, easy ones. Also, people have different innate skills. I am one who does not do so well remembering esoteric character combinations. I use regex frequently enough to understand how it works, and what I need, but without fail, I lack the "muscle memory" to just know what to type when doing much more complex than a simple match. This usually leads me to Google, or to a tool like this.
I have similar trouble with odd terminal commands and flags. I am not afraid of them, but it simply not part of my mental make-up to remember them all. The ones I use frequently - no problem. Those I use only occasionally - Google. :-)
Let's face it - regex IS HARD if you are not a regex "power user" or if you are the sort, like myself, whose mental map is not optimized for such things.
Yeah, I end up using more a tool called vim macros found in vsvim. They are very powerful. There are only really two commands to remember: record and play. I highly recommend them to anyone who doesn't use regex enough to remember them.
A day or two before he posted the list, he had to go through a run-around with some dude who apparently had copied a whole bunch of his (10 years+) blog content to their own, no attribution, nothing. I believe he deals with this type of thing frequently. I also think this tools list is a popular item for such "re-blogging,"
In this particular case, it appeared the offender simply didn't understand proper "nettiquette" and once pointed out, promptly removed the content (although he appears to still have a whole bunch of OTHER people's stuff copied up there, so who knows?).
So, kindly watch the way you throw the word "you" around. I did not write the article, I just wanted to see what the community might have to say about it. I am coming to understand MVC decently well.
That said, your points are good, and I agree, based on what I have learned myself to this point.
Totally agree about 50% of the joy coming from learning to use git. Frustrating at times, but in the end, that's the kind of thing that keeps me learning to code!
If I understand correctly, the subtree workflow is a (relatively) newer thing, and there is an actual subtree command either newly added or soon-to-be added which simplifies things a little further.
I decided to learn the old, hard way before I started exploring the subtree command itself (prior to the addition of the command, my understanding is that "subtree" represented a merge strategy, from which evolved the subtree "workflow" and out of which a git contributor evolved a "command," which appears to have been added to git 1.7.11:
I won't say any of this is hot, new information. This is my attempt to document the use of the subtree merge strategy/workflow in a way that would have helped me in figuring it out. While most of the information was out there, my best understanding came from working through multiple sources.
If anyone sees where I have something wrong, I would love to know so I can correct it. I do NOT want to be propagating bad information.
There is a real basic walk through for folks who are not deeply experienced with Git, and also a link to more of a reference for those who are more fluent and need less of the narrative/screenshots.
As always, feedback is appreciated.
One can be rude, and still be correct in their reasoning. I do believe that was the point here. Additionally, one can still engage in bad or unhealthy behavior and still recognize it as wrong.
I enjoyed the authors article. However, I think he misses the mark with some of his assumptions. Unlike some in this thread, I am NOT trained in economics. But:
1) I think the author incorrectly tries to nullify the family budget metaphor for economic prescription. While any metaphor only goes so far, he attempts to compare the micro-economic interactions within the family ("essentially communist") with the macro-economic revenue/spending/balancing act for a national budget. He misses the point that, in observing that we must "understand a family as a group of people functioning a single economic agent" we must consider the requirements of that economic unit to adhere to reasonable financial policies, such as making sure revenues are sufficient to cover debt service and expenses.
2) I think the author mis-characterizes the post WWII affluence of the American economy as a result of the wartime government spending combined with some magical wealth redistribution scheme inherent in a wartime economy. In reality, I believe the great American prosperity was more to do with the nation's near monopoly on manufacturing capacity after most of Europe was decimated (and Japan as well).
3) I agree with the author that "trickle-down": economics (actually more of a political thing than a real economic theory) is inherently flawed. I think he also misapplies the family metaphor here, as well, mixing the micro with the macro.
All in all this was an enjoyable and well-written article, and I appreciate the author's ideas about the "Robot Utopia." I don;t agree, but what fun is it if we always agree, right?
That doesn't mean a hiring manager wants to hear that, which is at least one of the points of the article. I do believe he refers to that idea, at least indirectly.
Also note, just because one loves programming does not mean one enjoys repetitively writing the same code, over and over again. Note to mention the fact that duplicating code within a project (instead of creating "reusable pieces of code") creates design problems and maintainability issues.
I believe most good engineers ejoy employing an elegant solution, and focusing on the problem to be solved. They don;t enjoy solving the same old problem ("Gotta write another data access layer now, before I can build the fun part of the app . . ." as an example) over and over again by writing what amounts to boilerplate code.
My experience is that when the problem is complex, the planned solution might still work, but there are often aspects I didn't think about that requires adapting the solution. So it's not just a matter of typing it up.
I think programming to a large extent is a learning experience, and you adapt the solution as you learn more trying to solve the problem. For me at least it is a lot more iterative than simply typing the solution.
Author here. I probably could have written 'I hate solving problems using technology' instead of 'I hate programming'. The point, as you noted, was that the challenge of solving problems with code never gets old. Rewriting repetitive code or just the simple task of typing certainly are not what great engineers enjoy.
I have similar trouble with odd terminal commands and flags. I am not afraid of them, but it simply not part of my mental make-up to remember them all. The ones I use frequently - no problem. Those I use only occasionally - Google. :-)
Let's face it - regex IS HARD if you are not a regex "power user" or if you are the sort, like myself, whose mental map is not optimized for such things.