Full-stack developer, most recently in healthcare and telemedicine; FHIR, HL7, HCPCs.

It's not a problem for the computer if you have a lot of code in a single file, but it is a problem for the computer programmer. If there's a lot of functionality in a single file, class, or other grouping of code, that makes it much more difficult for a human to understand and remember the details.

It's easier to work with a project if you can break it down into small pieces that are each individually easy to understand, so a goal of good project organization is to make your code out of small parts - small files, small models, a small number of lines of code - and have the parts be easy to distinguish and remember.

If you split one big "User" model into separate bits for billing, authorization, and user settings, not only is it easier to understand what parts there are, when you need to go in and make a change to the billing code, you immediately know that 2 out of 3 of the pieces can be safely ignored.

Similarly, if you take some very common functionality that models often have and generalize it, you only need to learn the general version once and then it applies to each of the parts. That's what the article describes. Many models are "Searchable" or "Taggable", but you only need to learn how searching or tagging works once, and the same search or tag code applies in multiple places.

Rather than having questions which can be easily answered with access to research materials, the exam is designed to be difficult even if you have the textbook open on the desk right next to the exam. Take-home exams often specifically grant permission to use the textbook and any other class materials.

Because a take-home exam is built on the premise that the student will have access to all of their materials, the professor writes the exam expecting that you have attended all the classes, read all the textbook chapters, and understood all the notes, so the exam is much more difficult!

It's also meant to make exams more like real work. Nobody at my company gives a damn if I need to crack open a math textbook to find an algorithm, or Google something - but a real job requires that you can understand and synthesize the information you find. You can't build an entire (...good) product out of copy-and-pasted answers from Stack Overflow but you can look up specific issues or points where you get stuck.

Remember that we're seeing this story because the students failed to get away with cheating - in part precisely because of the nature of the exam. One of the questions is an open-ended invitation to pick two events and explain them, and it's very suspicious if a group of students all pick exactly the same two events and present similar-sounding explanations.

Denis-Courmont may have licensed his code under GPL for a reason, but it can very well be a bad, zealous reason. Indeed, I would expect that almost every person who truly is a zealot and a bad apple would choose to license their code under GPL. The GPL is a license that demands total obedience to a particular ideology of software distribution, and requiring that other people obey your ideology in every detail is the defining characteristic of a zealot.

As I keep looking at this, it seems that it's most valuable when you consider the patch as an element of an event-based system, where you're storing or operating on changes rather than just the data. The reason it helps with a bulk editing process is that you want to know what changes Alice and Bob made if they both submit at the same time - operating on diffs simplified the system. For other systems where you operate on diffs, like an audit log, it's helpful to have a first-class format that defines the diff on a JSON document.

I think that's the biggest caveat I'm seeing with the proposal. It's pitched as a way to handle HTTP PATCH requests, but a format that defines "diffs on JSON documents" is most suited for systems that primarily store JSON documents and diffs on JSON documents - it is much less broadly applicable for "HTTP servers that accept JSON data", since frequently they only work with JSON over the wire, not as the ultimate source of truth. If you don't store JSON documents as the ultimate source of truth or have a domain-model reason to want diffs, I'm unsure of the advantage.

Other commenters have brought up size - that the patch must be quite a bit smaller than the whole document in order to gain a benefit - but I'm not sure it's useful even then. JSON is typically the representation of an object for transmission over the wire, not its final representation on the server.

I have a Rails servers with a JSON API, but it stores information in a SQL database where the columns roughly correspond to the JSON keys. I'm not actually storing JSON in the database and the mapping of JSON key to database column is not always one-to-one. That means if I want to accept a patch for an object with JSON Patch, I need some way of applying the patch "upstream" to the SQL row that is the source of truth for the object. And, of course, for a database with a schema, only a strictly limited subset of potential JSON Patch objects submitted can actually be applied.

The architectural benefit of accepting JSON Patch as an update is that "it's just JSON", but in order to apply a patch on pure JSON, you must have pure JSON and store pure JSON. It's now common for servers to use JSON but that doesn't mean it's "JSON all the way down". In the case of my Rails project, I would need to generate the JSON for an object (or retrieve it from the cache), apply the patch to that JSON, then treat the result as if it had been submitted as an entire document to the update endpoint. Instead of parsing received JSON, I need to generate JSON, process a patch, then parse the result. Whether or not the client has to deal with the entire JSON document, the server has to do so.

Now moving the burden to the server can actually be a very important improvement if that's where you want to do the work, but I don't know that you need a new standard of JSON document to do that - if you want to perform small updates on large objects, you can write the server such that clients are allowed to omit key-value pairs that are not to be changed when sending JSON to update existing items. Perhaps I'm just dense, but it seems like you only need to iterate through the keys that are included and update only those fields.

JSON Patch is a defined format for doing that but it adds a layer of abstraction to the operations, when you actually would want clients to be concrete in specifying keys and values so the server doesn't have to perform lookup to figure out which value is under which path.

Likewise for the concept of "synchronizing" structures, the problem is that you cannot apply a patch correctly unless you start with the same JSON before applying the patch. I don't know if the speed gain from sending patches instead of entire documents justifies the extra reliability work you need to do to make sure the synchronization eventually succeeds. Plus, just as you don't save time in the code to apply a received patch unless a JSON document is the canonical "source of truth" for that object, it takes work to generate a patch for another party to apply unless a JSON document is the "source of truth" and you can cheaply produce the diff in terms of JSON. (Like any document format, you CAN process and produce the data eventually, but the question is whether it's easier than alternatives.)

It seems like this could be useful for a system where you specifically want to store the changes to an item - i.e. an audit log - but I don't know if JSON Patch is substantially better than existing ways of doing that. Before reading this paper, if I was asked to write a project that stores the changes to a chunk of JSON, I might have done something like insert a \n character after each key-value pair and store the history as commits in git. That's a hack, but since JSON is text and developers already have lots of ways to manipulate text, I'm not sure why it's necessarily better to work with the state changes as "JSON that is changed by events that are also JSON" rather than "text that is changed by events, and the result always parses as JSON", since there are already good tools for working with plain text and evaluating changes to the text.

I can see this being useful in a system where you have really set a deep architectural assumption that it's "JSON all the way down", and therefore a JSON Patch can be treated with some level of abstraction rather than just being a well-defined shorthand for sending fewer bytes over the wire. If the system is a document store that considers arbitrary JSON to be the unit of storage, then you don't need to worry about mapping into alternative storage formats. However, that seems like a very specific subset of the architectures in the world of "servers that communicate with JSON".

This is the danger of having a 'test org' separate from the 'dev org'. When writing tests is tied to writing production code, your progress in one is tied to progress in the other. If it's easy to write tests for a particular feature, then the developer stops writing tests and writes the feature once they're done with the easy tests. It's much easier to understand your coverage when you're actually working with and writing the code being covered, rather than working in some separate "test org" - you don't need to run a coverage tool, you just see what breaks if you comment out a chunk of code. If the answer is "nothing" then it wasn't covered!

At the end of the day, an automated test suite is a product for developers on your project in the same way that a car is a product for drivers. You will have a hard time making a car if nobody on your car-making team can drive, and you will have a hard time writing a test suite as a tool to develop Project Foo if nobody on your test-writing team develops Project Foo.

I now write a project where I handle both the code and the tests. In the same way that my production code is improved by writing tests, my tests are improved by writing production code. I know what is included in the test coverage in the same way that I know what I had for lunch today - because I was there and I remember what happened. Tools for checking coverage are an aid to my understanding; in a company with a separate test org, you don't know anything about coverage until you've run the tool.

For example, if you personally tend to write off-by-one errors a lot, it's a good idea to write tests which check that. On the other hand, if you almost never write off-by-one errors, you can skip those tests. If test is cheap to write, easy to investigate, and covers a piece of code that would cause catastrophic problems if it failed, it's worthwhile to write the test even if you can barely imagine a possible situation where it would fail - the degree of the cost matters as much as the degree of the benefit.

You don't "know" when it's OK to nuke a test just as you don't really "know" when it's safe to launch a product - you decide what you're doing based on experience, knowledge, and logic. The important step many don't take is developing the ability to distinguish between good tests and bad tests, rather than simply having an opinion on testing in general.

That is the point of the "changing behavior" rule - you do not gather the benefit of running a test until it has failed at least once, and the benefit gathered is proportionate to the benefit of the action you take upon seeing the failure. The tricky part of the rule is that you must predict your actions in the future, since a test that might have a very important failure later could pass all the time right now. Knowing your own weaknesses and strengths is important, as is knowing the risks of your project.

There are possible design benefits to writing tests, since you must write code that is testable, and testable code tends to also be modular. However, once you have written testable code, you still gain those design benefits even if you never run your test suite, or even delete your tests entirely!

I quickly realized that my job was futile - many of the "good" tests had already been written, while in other places, "bad" tests were entrenched and the "test dev" had the job of manning the scanner to check for nail clippers, or upgrading the scanner to find as many nail clippers as possible.

Here's a useful rule on the subject that I picked up from an Artificial Intelligence course back in the day: The value of a piece of information is proportional to the chance that you will act on it times the benefit of acting on it. We all realize there is no benefit in testing if you ignore failures rather than acting to fix the bugs, but in much the same way that doing nothing when tests fail has no benefit, doing nothing when tests pass also has no benefit - so tests which always pass are just as useless as failing tests you ignore, as are tests which only turn up corner-case bugs that you would have been comfortable with shipping.

If you're doing the right amount of testing, there should be a good chance, whenever you kick off a test run, that your actions for the next hour will change depending on the results of the run. If you typically don't change your actions based on the information from the tests, then the effort spent to write tests gathering that information was wasted.

I work mainly on an iPhone project. In order to handle customers requests for this or that custom UI feature, I invented a tool that generates something like a simplified XIB file from an image and a chunk of CSV. I made the end result of the tool a text file that the iPhone code parses.

Working in text saved a lot of time. Since I invented my own tool, naturally there were things to debug and tweak in the results, but I could do that with a text editor and commit the changes as easily diff-able deltas in git. Although I work on iPhone code, everything also has to be implemented in Android - but it's no problem for the Android developer to use the text file since it's just text.

I've also written tools for migrating chunks of customer data from an old back-end system to a new one using the new server's customer-facing API. This was partly for dogfooding purposes, since the API was new and had very suspect stability.

I wrote the tools to generate text files where each line is a JSON payload that would be sent to the server. It made everything easier to debug - examining the payloads lets you distinguish between errors in the export tool and errors in the API. The text files themselves could then become test cases if there was a bug in the API, or be quickly hacked to contain correct payloads via find-and-replace if the export tool was wrong but we still needed the migration to finish right away.

Methods are actions, not objects, so the most concise description for a method is usually a verb. Describing it as a noun instead requires adding prepositions and turning verbs to the gerund '-ing' form.

I realized this because I write both Ruby and Objective-C, and sometimes write basically the same thing in idiomatic forms of both languages. In idiomatic Ruby method-chaining, your code is a series of verbs with the relations between the actions defined by the '.' or the '()' signs, rather than by words such as 'to', 'from', 'with', or 'by' present in the name of the method.

One is a claim based on difficulty. X is really hard, so if you can use it successfully, you must be an excellent programmer.

Another is a claim based on taste. You must be very sophisticated and knowledgeable in order to see why X is good, so people who choose X are excellent programmers, because they know the difference between good and bad technologies.

I tend to feel that you shouldn't take credit for having good taste in frameworks (or text editors, or etc.) until you have worked with more than one. Otherwise, even if you pick the 'best' one right off the bat, it was mostly luck.

I can tell you, however, that it's quite common for Rails programmers to not know much about Ruby except for the parts used by Rails. In the U.S., Ruby was popularized by Rails, and very few programmers learned the language separate from Rails. I'm unusual in that I picked up Ruby first (while visiting Japan) and learned Rails much later.

Rails is much more than a DSL - I would call it a framework, which includes several DSLs as sub-components - but for a pretty broad range of the complexity of your web application, you spend more time and code dealing with Rails library functions and DSLs than with 'pure' Ruby. In most cases, that's the point - Rails is useful precisely because it gives you library functions, DSLs, and middleware components that deal with common web app issues. Rails is a good framework precisely because you can use the framework instead of building things from scratch in pure Ruby.

Because of those factors, many Rails programmers don't know the underlying language of Ruby or understand it very well, and I think it's accurate to say that a common mistake made by Rails programmers is to misapply Rails-style conventions in other projects.

Rails programmers do have a reputation, in some places, of not being good programmers. (Whether the reputation is entirely accurate is another issue.) I think the most common specific complaint I've heard is that Rails devs don't know SQL because ActiveRecord does it for them.

The original article does assume that you're dealing with a system that more-or-less works. If your application flatly doesn't do the right thing, than a big rewrite from scratch may really be the best choice - there's nothing to save.

But spaghetti code doesn't just fall from the sky, it occurs because of politics, stubbornness, and bad processes. Over the course of the 10+ years it took to make the code base, is it really the case that nobody but you noticed the problem? It's more likely that there's a lot of pressure going in the opposite direction, and other maintainers didn't know what to do either.

Dealing with subsystems helps you handle both problems. Management might not be willing to let you rewrite the whole thing, but if you said, "Let's just fix the boot-up process for the Cyclotron 4000 resource. Nothing else changes, just the Cyclotron boot." you might be able to get permission. In a badly-maintained project, it's hard to replace all the instances of one service - that's what makes it 'badly-maintained' - but it's still easier than dealing with the whole system in one go. And, of course, instead of 'fixing' the Cyclotron you're actually rewriting it with a new, non-wacko Cyclotron service.

Then you go back to your manager and say, "It was rough, but the Cyclotron 4000 no longer blocks the start-up. Let's get the next thing on the list." Not only do you have a slightly better project, you also have better credibility with management, which makes it more likely you'll be listened to when you say a certain technical measure is necessary. Next, fix the subsystem that talks to the Cyclotron - and so on. Pick a right time to introduce tests, code review, and all the rest.

Remember that just as you had the experience working with the terrible code base, your managers had the experience of working with the previous 3 or 4 software architects who "had their own vision" and delivered a product that doesn't start up reliably - I don't think it's surprising that there was no longer the political will to assign people to refactoring or rewriting tasks. Bad architecture uses up the political will needed to approve good architecture, because it makes all "architecture" tasks look bad. You need to regard you reputation as a finite, under-supplied resource just as much as your time and budget and plan to get more.

From your use of the past tense, it looks like you're no longer in that situation (good for you!)... but that would be my advice if you see a similar situation in the future. I've used this plan in my own career to rewrite a (much smaller, only moderately troubled) project piece by piece over the course of a year.

There are two problems. One is that an orderly transfer of control requires a certain amount of planning and coordination, which are precisely the resources that aren't available when a maintainer has left (or is on the way out). The other is that people tend to become maintainers of other peoples' projects by climbing the open source 'career ladder' from user to minor contributor to major contributor; projects are stable when they have enough contributors that the most-productive non-maintainer can be promoted to maintainer status when the original author leaves.

GitHub helps by making it easy and obvious to fork something and eventually have your repo promoted to be the 'official' one, but as with many problems in open source, finding a particular, specific person who actually does that is the hard part.

[1]http://thechangelog.com/post/1986814704/stillmaintained

Part of it is an integrity problem. In addition to describing your small business as a startup for marketing purposes, you might also call yourself a startup in order to make other claims - such as telling employees that their stock options are extraordinarily valuable, or making a rule that everyone must work 80 hours "just like the other startups".

The flip side of the principle that exceptional businesses require exceptional effort is that almost all businesses are not exceptional.

[1]http://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_P...

First, polls have shown that U.S. citizens drastically overestimate the amount of the federal budget allocated to foreign aid. As I recall, the average estimate is 25%; the reality is less than 0.1%.

The comparison holds mainly not because Bill Gates is so rich, or because the U.S. is indebted, but because federal budget priorities drastically favor items that are not foreign aid. Those priorities are formed in part because citizens believe that the budget is already giving away huge quantities of money, making proposals to increase foreign aid unpopular.

Second, the amount of money spent is not necessarily a good measure of the amount of aid given. On the one hand, sometimes more money doesn't help; to use an analogy that people here might understand, after a certain point in increasing your budget for paying software developers, you are limited by your ability to find good people, not by your ability to pay them. Likewise, some foreign aid projects - such as HIV eradication in certain African nations - have reached the point where the amount of monetary aid given already exceeds the capacity of local infrastructure to use the resources wisely, and any more would just sit in a bank account somewhere until someone blew it on a useless boondoggle.

On the other hand, some forms of aid or assistance given by the U.S. to friends or allies do not have monetary value, such as military assistance, diplomatic cover, or political advice... and there are material goods that are, for whatever reason, more valuable to the people who receive them than the items would be priced in the U.S. market where they were paid for.

So although this is a true and revealing fact, it's best to not misinterpret it. The reasons for the foreign aid budget being lower than Bill Gates's charity contributions are political, not fiscal; but it's likely that the more important question about foreign aid is the nature and quality of the aid, not the U.S. dollar value for which it was purchased.