It's excessive if your goal is _solely_ to execute a repeating AJAX request. But, if I'm understanding the attack correctly, this script is injected _in place of_ jQuery requested from Baidu's CDN. If you want the affected sites to appear normal, so the users whose browsers you are highjacking will contribute to the DDOS for the longest possible period, then you want to ensure that jQuery does indeed load.
The OP further clarifies why jQuery is injected _twice_: seems the injection is occurring only for 1% of requests. So it appears the code is looking to see if it has triggered the injection itself, and fires another request if needed.
For the last three years or so, I've been telling anyone who asked that ORM is an antipattern, to be avoided at all costs. I've settled into wrapping all queries in classes, with any parameters exposed as public properties. The SQL is written inside the class, essentially in a template. When necessary, the generated query can change based on the values assigned to the properties. All the mechanics of how the query is executed and passed to the database get rolled up in the base class, with a public method that returns the dataset returned by execution. Then I just run the dataset through transformation functions to get the data structures I actually need - combining multiple result sets if necessary to build really complicated objects when I have to.
I've been building this approach for a couple years now, and I haven't regretted it for a minute. I don't have to fit my databases to the vagaries of the ORM layer, and I have full control over my queries. I NEVER want to go back to ORM :)
> If you are taking data out of a relational database and mapping it into objects, you are implementing an ORM.
No, ORM is a particular approach to doing that; the query abstraction approach described upthread is closer to the DAO pattern, to which ORM is an alternative. People were using RDBMSs to provide a persistence layer for OO programs before ORM was a thing, but as you have broadened the term any use of an RDBMS to store/retrieve data used in an OO program would be "ORM".
Now you're the one using a nonstandard definition of ORM. Here is how Wikipedia defines it:
Object-relational mapping (ORM, O/RM, and O/R mapping)
in computer science is a programming technique for
converting data between incompatible type systems
in object-oriented programming languages.
I believe the difference here is that one is an ORM framework, while the other is just objects bound to a database.
ORM frameworks usually allow you to drop down to SQL. But then you're stuck in that terrible world of depending on poorly-documented and soon-to-be-deprecated (or already deprecated) internals. Which are pretty much guaranteed to not fit what you really need anyway. Then you have to bridge your hack objects with the "proper" ORM objects. Your crufty hack objects will probably never be seen as first-class citizens in ORM land, forever banished to edge case hell.
I've used this pattern and I like it a lot (for the reasons you say) but I find I still spent way too much time on really mundane stuff... particularly table<-->object mapping if the database table has a lot of columns.
My current approach is:
1. I basically judge ORMs on how easily they allow me to use custom SQL. (ActiveRecord makes this pretty tolerable with find_by_sql)
2. Let the ORM handle as much CRUD and table<-->object mapping as possible
3. If I have complex SQL, I try to wrap it in an appropriate database object (view, sproc, function).
Seconded. What I notice most when I'm on the verge of burnout is a lack of capacity for stress. Say when something breaks first thing in the morning - under normal circumstances, it's cause for some grumbling and maybe frustration at the time taken out of your day. When burnout is at hand, I'm just out of my mind. I don't have the tolerance for even the minor stressors, and nowhere close to my normal patience for the slow, thoughtful work necessary for top performance.
Burn out - for me - means a shorter temper and less productivity.
That really cracks me up! I work in C# probably 80% of the year (python and shudder vbscript make up the remainder) and I use lambda statements, implicit typing, and anonymous functions almost every day. The Linq IEnumerable<> extensions are also pretty well indispensable for me. My biggest complaint with C# is the limitations imposed by the static typing system: anonymous functions can't be generic, so you're forced to either declare delegates or explicitly declare each of your anon signatures; and KeyValuePair<> and Tuple<> both force you into sometimes excruciatingly, comically long object declarations, eg
I've come to a point where I can comfortably write functional code in the language (though I should stress that I don't write "pure" functional code; I don't fall into the camp that abhors side effects in all scenarios). Day to day, it really is a fine language to work in, notwithstanding a few warts. In all honesty though, I'd rather be working in Python or a LISP most of the time
For me, LINQ was definitely a "gateway feature" to the lisp world. If you still use C# at work, I strongly suggest checking out F#: https://news.ycombinator.com/item?id=7048522
I'm pretty much in total agreement with you, but to nitpick on one thing you said:
> as is publicly condoning breaking the law in reaction
_Peaceful_ civil disobedience campaigns played a large role in the Civil Rights movement and helped raise awareness leading to (in the US, at least) the Civil Rights Act - thereby reinforcing equal protections and voting rights.
The intent is important; and the NONVIOLENT aspect is especially important. But civil disobedience isn't always necessarily a bad thing. Nor is it always a childish suggestion.
I get the accusations of money laundering and narco-trafficking, but where are the computer hacking accusations coming from? I didn't see anything in the complaint that specifically alleged deliberate intrusions into any systems. Does this mean Justice is going to accuse him of computer hacking because he hired virtual servers and used them to run a criminal market place? That would sound like a stretch of hacking laws, right? What am I missing?
I very much want to come up with a coherent and inspirational repudiation of the OPs thesis. This is the second essay I've seen recently that seems to completely miss the magic of our trade, and I feel like we need some strong cheerleaders to counter this stuff.
How does a programmer NOT wake up every morning with a head full of inspired, flaming joy at the thought of what we do for a living? I've been at this for 5 years now (putting me in the same generation as OP, and the other blogger I came across) and I'm still ragingly in love with this craft. And I (_just_, you might say) write web apps. Yes, there are tedious days (we are, as many have stated WORKING, after all). And yes, sometimes the nature of constantly shifting specs leads us into some ugly code - but that's the nature of writing and designing to meet the needs of customers; sometimes customers really just NEED something that isn't very pretty.
But the root of what we do is this: we conjure ideas from memory and imagination, commit them into words and incantations in the terminal, and send out our instructions to be carried out by the machine. Making our will manifest through a medium that is almost completely malleable to our intentions. If there's another trade out there that's more nakedly similar to "wizard" I'd love to hear about it. What we do is barely-adulterated magic. And there is so much room for improvisation, art, and beauty in the crafting of our instructions, that even a simple CRUD interface can become a work of glory.
I freely admit that, in my enthusiasm, I'm sounding a bit deranged. And I'm painting this in a bit more glowing light than most day-to-day coding deserves. But it pains me to see a programmer with such a negative outlook on programming. And when that view gets touted as a warning against being a coder, I feel those of us who really and truly enjoy our trade need to be standing up and making the counter-argument - with all the ardor and enthusiasm it deserves.
Addendum: and OK, so the OP may not be making the claim that "programming" itself isn't what's bad, it's the JOB that's bad. It's writing the code that our clients need, day-in, day-out, that's bad. My counter-claim to that: writing bad code is a choice. You can look at every problem that comes to you as "just more toilet cleaning", or you can look for the aspects of the problem that separate it from all the code you've written before, and start writing the correct, clean, elegant response to it. And if you're solving the same problem a second time, well it ought to be that much easier than before, right? If you solved the problem PROPERLY the first time, there should be very little work in solving it a SECOND time. So now you find yourself getting paid to do less work, while - hopefully - leaving yourself room to more fully commoditize whatever process you've found yourself on, making it easier to KEEP getting paid while doing less and less work each time. With your remaining time, you solve OTHER problems, and continue filling the pipeline with magic and money.
Seeing the job as tedious and boring starts as a choice you make yourself. Getting back the magic you felt in your youth is just a matter of remembering it; and choosing to see it in the next project that hits your inbox.
I'm in total agreement. I find programming just so fascinating and beautiful in a way that's like nothing I've ever seen or imagined. I find everything so sublime, and I'd still say that at 2am at the end of an 8 hour solid programming session.
I'm much newer to this (one year and still studying) but I really hope I can feel this way for the rest of my life.
At it's core, what is programming? It's the skill of being able to leverage turing machines, symbol manipulators, to an end.
In a world being eaten by software, in a world where information is on its way to becoming the most atomic unit of value, it's hard to imagine a more profound and useful skill.
I'll avoid the personability side of the question, but focusing on the "change" aspect: Let's not confuse "physical" tools - like a hammer, press, CAD program, or text editor - with "thought" tools - like a paradigm of programming, say, Functional or Object-oriented.
I'm still a rather young programmer (only about 6 years into my career). But I've found myself actually working in a reverse flow of technology, in terms of what tools I use on a daily basis to do my job. I'm primarily a Microsoft-stack web applications developer. I spend most of my day writing out c# and t-sql; often, using Visual Studio and MS Management Studio to interact with my code and the database. Those are the tools I used at the start of my career, when really getting the hang of basic programming.
As I've moved forward (career-wise), I now find myself using rather "older" tools for my day to day tasks. I hate to touch a Windows machine without Cygwin installed, as BASH is my primary interaction with the computer now. And I find myself generating code at a faster pace in VIM than I can in VS. As I've started using more Postgres databases, I've grown more comfortable with psql, and the terminal-based interaction with the db.
So the actual tools I'm using to generate my work are, in a sense, "old". I've found myself almost shunning new tools. Or at the very least, not embracing new tools _just_ for the sake of them being new. A new tool has to have some value aside from "newness."
Use of these "old" tools is not to say that my skills as a developer are lagging behind, however. The same even goes for the languages I've been using for personal projects. I find myself working out ideas more quickly in Common Lisp (how's that for old?) than I can in c#.
The point I'm trying to make is: don't focus on whether or not the person is using the newest tools to do the job. What's going to matter more is how well they understand the fundamentals of their discipline. Granted, I'm still young, but I feel like the craftspeople that really understand the core principles of their craft, and keep an eye on the horizons of their craft, are going to remain in demand (so long as the craft is needed). And if that craft is software development, it won't so much matter whether the coder is embracing Rails or not; what will matter is that s/he understands the new ideas that Rails might embody, and can incorporate those ideas into their daily flow.
