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.
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.
In truth, I looked around the DZone article (which is how it is referred to on the DZone site). When I couldn't find a readily visible link to the original, I assumed is was content written on the DZone site, much like articles on CodeProject (as opposed to technical blog links on CodeProject, where there is a clearly identified link to the source).
My bad, but please know I understood the guideline, just not the page I was linking to . . .
Absolutely a step in the right direction. How is it that, in the world of tech patents, the petitioner (the patent troll) does not become obligated to pay attorney fees and costs if the respondent prevails?
I think the limited scope of Twitter is/was one of the strengths of the platform. Unlike the various walled gardens growing out of every corner, trying to be everything to everyone, Twitter was very effective for a specific style of communication.
They should monetize access to their API with some sort of tiered data-volume scheme. Under a certain amount per month = free, over that, begins to incur charges. They could also allow anyone to develop against it, with a license which acknowledges a cut of revenue over a certain amount.
I am still learning programming the hard way - namely, by checking out how other folks do it, then struggling to do it myself. However, I've learned enough, I think, to get the impression that some people get rrrreeeallly attached to their architecture.
I have come to believe that all these models, "patterns" and such are very useful tools, but only that. Seems like we keep having these religous wars about language, patterns, architecture, whatever.
All of it is only useful as long as it, well, useful. When the "architecture" starts hindering the function, it has stopped doing it's job.
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.