Finish your stuff - <AUTHOR> http://250bpm.com/blog:50 <comment><USER2> What would that look like?

Consider an example:

You have made a little web app that beeps at certain times of the day to remind me to do something.

Is it complete?

Oh, you want a calendar integration. That makes sense. You add it. Is it complete?

Oh, you say you want to release mobile versions? Okay, now is it complete?

Sorry, but the iOS version needs to be updated to remain compatible. Now is it complete?

There is a new popular cal app that everyone uses. Should you update it to work with that?

The problem isn't that the software is incomplete. The "problem" is that the world keeps changing.

To the extent that the environment doesn't change (unix), you can "complete" your tool.

<comment><USER3> That is called feature creep, and is usually not viewed in positive light. Its real art to know how to decompose problems and design neat, contained, solutions.

I'd also argue that the "change" you are seeing is mostly illusionary, but that is another story altogether.

<comment><USER4> > neat, contained, solutions.

Contained solutions can be only designed for contained problems. Sure if you define a limited set of requirements you can finish your project and will have a limited software that is only useful in that very limited context.

"change" might be unnecessary but it is certainly not illusionary.

<comment><USER5> Then you split the problem into contained pieces.

<comment><USER4> But then you didn't solve the problem. You solved pieces of the problem.

<comment><USER6> That's a part of software engineering though.

Once you reach a certain scale, you have to decompose your problems into subproblems. You solve those and assemble them into the final system.

The people making AMQP (following the original author's example and line of reasoning) were solving too many problems: they had a message queue, they had a wire protocol, they had service discovery, etc. This is all _fine_.

The author and others went on to make ZeroMQ with the intention of focusing on the communication between nodes and various communication patterns (pub/sub, reply/respond, etc.). They had some work on what should go over the wire but not too much, and they didn't expose things like authentication or discovery of services. Why? Because those are critical to applications, but not to a distilled, core message queue.

Using ZeroMQ, now, you can build up to what AMQP wanted to be. You can agree between your customers that ZMQ will be how you coordinate between systems, but you define your own message format using a separate standard. That standard is now independent of the wire protocol as well. Take something like ASN.1 or protocol buffers and define your message schema using those.

You want discovery? You agree on how services should be announced (a schema in ASN.1) and where the service registry should live (this would be a system configuration detail, where you specify where your system looks for a registry, maybe even federate registries). But this doesn't redo the work of ZMQ or the work of the serialization/deserialization format defined above.

You want to handle authentication? You pick your desired authentication protocol (public/private keypairs for identity, a capabilities based system, access tokens, whatever) and you again define a schema, define where the authentication service is located (or how it's identified in the registry above) and continue.

We don't reinvent TCP every time we want a new network protocol (well, some people do). Why would you reinvent the message queue when its already been distilled to a basic and fundamental framework that can be used to implement your desired business logic (now, if the MQ lacks some features that are basic or primitive, then it should be extended because it's not complete).

<comment><USER7> > We don't reinvent TCP every time we want a new network protocol

Hey man, speak for yourself. Reliable UDP is where its at.

<comment><USER6> I had "(typically)" in there originally. Should've left it, but it's complete so I won't change it now.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> There is a whole class of rhetorically attractive analogies comparing programming to the building of physical things like furniture, bridges, and buildings. They usually overlook that software requirements vary greatly and can be quite complex, while the physical requirements of a chair are not going to vary much across chair designs. Modification of software requires no physical resources and can be executed at scale (e.g. package managers), while modifying the design of a chair once it has shipped is impractical. Software errors can certainly be consequential, but I'd much rather encounter a bug in a messaging queue than a defect in the chair I'm sitting on or the bridge I'm driving over.

<comment><USER6> > They usually overlook that software requirements vary greatly and can be > quite complex, while the physical requirements of a chair are not going to > vary much across chair designs.

I feel as though that's somewhat addressed in the essay:

      Yes, I hear you claiming that your project is special and
      cannot be made functionally complete because, you know,
      circumstances X, Y and Z.

      And here's the trick: If it can't be made functionally
      complete it's too big. You've tried to bite off a piece
      that's bigger than you can swallow. Just get back to the
      drawing board and split off a piece that can be made
      functionally complete. And that's the component you want
      to implement.

Software engineering is an offshoot of systems engineering, which is often described as "managing complexity". I don't think it's at all unreasonable for people to look at the methodologies actual systems engineers use and learn from them. One of those things is decomposition of tasks, what this article is about. If you're making a message queue system, divide it into subsystems that are each more feasible. Your over-the-wire data format protocol is one thing (asn.1, protobufs, etc.), your concurrency library and patterns in your systems are another (go's channels, erlang's processes, libmill from the article), your database is another. Once you have your system decomposed in this fashion you can do each part, and actually finish them, and assemble your complete system by combining them.

Once they're small enough the Unix philosophy applies. Write components that do one thing and do it well, and design them in a way to communicate with each other.

<comment><USER9> > If it can't be made functionally complete it's too big.

Too big for whom? Most people on HN aren't building systems software or embedded software with a strictly-defined purpose; they're building an app business or a service business, where the "purpose" is "to make money" and adding additional features or "checkboxes" are how you attract more customers to make that money.

A _program_ can be done. A _product_ usually can't be, as long as its authors want to continue to rely on it to put food on the table.

</comment></comment></comment><comment><USER10>
        Out of the frustration with AMQP I've started my own ZeroMQ project.

I doubt that Martin was the sole initiator of ZeroMQ project. I think that late Pieter Hintjens, the original author of AMQP, deserves some credit as well, at least out of respect[1][2].

[1] [https://en.m.wikipedia.org/wiki/ZeroMQ](https://en.m.wikipedia.org/wiki/ZeroMQ) [2] [https://en.m.wikipedia.org/wiki/Pieter_Hintjens](https://en.m.wikipedia.org/wiki/Pieter_Hintjens)

Disclaimer: I knew Pieter personally and met him several times at his home and at conferences.

<comment><USER11> As someone who only discovered Pieter by finding his last article posted on HN, and then subsequently learning a lot from reading many of his other articles on his website (different perspective on life, humility, consulting in tech outside of SV, presentations), here is his homepage for those who are curious: [http://hintjens.com](http://hintjens.com).

Three examples I'd recommend:

Life, Consulting, Humility, Calming Down: [http://hintjens.com/blog:125](http://hintjens.com/blog:125) (confessions of a necromancer)

Presentations: [http://hintjens.com/blog:107](http://hintjens.com/blog:107) (ten steps to better public speaking)

Life, Humility, Time: [http://hintjens.com/blog:123](http://hintjens.com/blog:123) (fighting caner)

He's one of the few online writers who keeps my attention no matter the length. His humor is fun and his imagery and story telling style are engaging.

[edit: formatting]

</comment></comment><comment><USER12> Finish your work... only to have legions of newb "hackers" bitching at you and calling your project dead because "(s)he hasn't posted an update in months"

Death to evergreen software! Let projects be finished!

<comment><USER13> This is a really good point. I'm guilty of seeing a repo that hasn't had a new commit in 18 months and choosing not to use that code because it's 'not supported any more'. Maybe maintainers could help by making it clear that their code is still supported but just doesn't need any changes in the Readme or something.

</comment></comment><comment><USER14> I get the problem with feature creep (who wants a text editor that also implements support for tetris?! ^•^), but as others have pointed out, that sentiment probably isn't precise enough to be all that useful.

Being a command line junkie, what stands out to me is the composability of my tools. This composability, I feel, is the key that let's us separate concerns and write small, standalone tools.

<comment><USER15> > _who wants a text editor that also implements support for tetris?! ^•^_

Well, I do :) - given that said editor also has better UX than mainstream operating systems (in terms of efficiency, extensibility and interoperability), and it's because of that it is possible for someone to implement Tetris in it.

</comment></comment><comment><USER16> This sounded oddly familiar, until I read about the projects Libmill and Ribosome. And yeah it's a post already submitted in 2015 and should be labeled 2015.

<comment><USER17> The link to Ribosome led to a shopping site, I was disappointed.

<comment><USER18> Found the repo - [https://github.com/sustrik/ribosome](https://github.com/sustrik/ribosome)

</comment></comment></comment><comment><USER19> Any software tool that is deemed as "complete" is not really complete. Even TeX, which will be releasing its final version when Donald Knuth feels the end of his life is near, is not complete because it is constantly expanded with reimplementations like XeLaTeX and LuaTeX and with thousands of plugins in constant development. GNU utilities like ls are not complete because they are built on top of operating system syscalls which are changing due to updated filesystems, and on glibc which releases a new version every 6 months. A change upstream might trigger ls to be changed, so it's not finished, just evolving slowly. Just look at its git history [http://git.savannah.gnu.org/cgit/coreutils.git/log/src/ls.c](http://git.savannah.gnu.org/cgit/coreutils.git/log/src/ls.c), where the last change was _three weeks ago_. GNU Make, mentioned in the article, is still evolving. Look at _its_ history. [http://git.savannah.gnu.org/cgit/make.git/log/](http://git.savannah.gnu.org/cgit/make.git/log/)

<comment><USER6> Re TeX: That's actually covered by the author. TeX itself is complete. Knuth isn't adding new features, instead the version number is converging to pi (new digit added) with bug fixes [0]. The other variations are not TeX (they're reimplementations) or they're extension built on top of the completed TeX program.

[0] [https://www.tug.org/TUGboat/tb11-4/tb30knut.pdf](https://www.tug.org/TUGboat/tb11-4/tb30knut.pdf) [PDF, in case it wasn't obvious]

<comment><USER19> Yes, that's what I meant to imply. So yes, TeX is finished software but the boundary between what is known as TeX and "not TeX" is blurred by the thousands of extensions in the TeX environment that people _must_ use when using anything beyond the basics.

Basically what I'm saying with that example is that you can draw a line around some code and say "this is TeX, and it is finished." But what users mean when they say "I use TeX" will never be finished and will be forever expanding.

TeX is the hardest to argue because it is probably the most stable software in existence for what it's capable of, so any other software you use is much less finished.

<comment><USER9> > the boundary between what is known as TeX and "not TeX" is blurred by the > thousands of extensions in the TeX environment that people must use when > using anything beyond the basics

I would say the boundary is very well defined.

Consider Internet wire protocols: to access this website, you're using HTTP over TLS over TCP over IP [etc.]

That doesn't mean that TCP or IP are "changing" when HTTP or TLS change. TCP and IP are feature-complete, low-level layers that each just do one thing well. We add on more layers to get the effect we want, and those layers change frequently, but changing those layers doesn't mean the lower-level thing "changes" as a part of it.

I think the problem with TeX is just that people have the nomenclature flipped. People think of things like LaTeX as being "what TeX is"—that LaTeX "is an implementation of" TeX. But that's off; it'd be like saying that HTTP is an implementation of TCP/IP, or that Ubuntu is an implementation of the Linux kernel.

In reality, LaTeX et al are _software distributions_ —they _include_ TeX as their text-constraint-processing engine, just like a Linux distro includes the Linux kernel, or a Unity game includes the Unity engine. It's one component, with a well-defined function.

</comment></comment></comment></comment><comment><USER20> I respectfully disagree.

While it's very good to encapsulate functionality, and have stable and well- defined interfaces, there is also a great value to having a unified platform and community that builds interoperable things.

Would you rather assemble your project from 250 different libraries, some of which may be incompatible with other ones? Sure, each may solve a tiny problem, and they may all be orthogonal (best case) but there is a major need for a unifying paradigm above all those components so they can all work together.

Here is a counterpont to solving tiny problems: [http://www.haneycodes.net/npm-left-pad-have-we-forgotten- how...](http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to- program/)

Basically, I prefer to have a growing community working on a growing snowball of components that are all interoperable and can be assembled like lego bricks. I think Wikipedia has such a community. RDF has several such a communities. The Web has such a community. This really creates a lot of value by having an exponentially growing platform where many thing works with many other things.

<comment><AUTHOR> Tiny problems that are solved provide a common part that many people can be reasonably sure is free of bugs - if thousands of people use left-pad, you can be reasonably assured that it has no bugs (or else people wouldn't use it, or a bug report would be filed - "many eyes make all bugs shallow"), if a thousand people write left-pad, you will get many versions with bugs that are never found, because there is much higher entropy/surface area.

<comment><USER20> I agree with that, but I just think there should be some overarching platform / interoperability into which all these small pieces can fit. And also version pinning in package managers, where you manually check diffs and compatibility before upgrading anything.

</comment></comment></comment><comment><USER21> The whole point of software is that it is soft. Malleable. Ductile. Thats the strength and sometimes a weakness. It makes software hard to deal with. See the many late projects. But that also makes it awesome because you can change it with changing requirements.

Yes, it's important to generally finish what you start. Equally important is the capacity to accept, learn and make changes

</comment><comment><USER22> software is never complete. It might be usable (in the world outside personal projects perhaps "shippable") but never complete.

I think the point the author is making is to not start projects that aren't likely to have a minimum viable product that is usable and achievable within reasonable time.

I'm not so sure. It's more fun to write the skeleton of a compiler and abandon, than it is to write something minimal sometimes. The only (proper) way to learn what tradeoffs exist in sql database design is to make one. Making a sql parser, btrees and so on is HARD but rewarding. After a week you'll know a lot about a lot of things. But you likely won't have a working SQL database. If you aren't a very special kind of crazy you won't reach the finish line and you'll abandon it somewhere along the way. So was it all a waste? Is exploratory hobby programming somehow a bad practice? I can't see that it is.

<comment><USER6> The point of the author is to define your targets. When you're building a compiler if you're also building a parsing engine then maybe the parsing engine should be its own project, with the compiler a separate project that uses the engine. When you build a web app you don't closely tie in the web server code, you use an existing or build a new web server. When building a web server you don't build the TCP stack with it. You make the TCP stack and then have the web server use it.

Complex systems are constructed from smaller, less complex subsystems. Complete them, let them standalone and build out our final systems from them. We generally don't rewrite tools like grep because it exists and it works well, we may port it to new platforms. And we don't change the effects of the -R flag out from under the users (clients), it is what it is. The interface is, essentially, completed.

If you're leaving incomplete hobby projects in your wake (all of mine are), that's not what he's talking about.

His specific experience was going from AMQP (large, complex specification) to ZMQ (smaller, focused on the essentials and let complexity be built on top) to nanomsg and libmill (even smaller, more focused). So in theory his nanomsg and libmill could be considered complete, as we'd consider TCP "complete", today (from a client perspective at least). And we can work our way back up plugging it into systems to recreate the capabilities of ZMQ, which can be plugged into systems recreating the capabilities of AMQP. Which can then be used to solve our business problems.

</comment></comment><comment><USER23> I find this funny coming from the originator of ZeroMQ. When I firt tried out ZMQ it took me all of 12 seconds to figure out that if you didn't pass exactly the message that it was expecting, it crashed the server.

That problem along with I'm sure hundreds of others were fixed along the way.

You don't achieve perfection in software development. Ever. Even when developing something for yourself where you define the scope and you leverage it for a menial task. There's always better. There's always more robust. There's always something else you can do.

That's the draw to software development for many of us. There is a constant challenge awaiting our brain. You can consistently push yourself in a new direction that you care about.

The downside is that feeling of a completed accomplishment really is just an arbitrary release ceremony. What software developers need to get good at is letting go and moving on.

</comment><comment><USER24> Great software projects are never finished; instead they always evolve and improved similarly to living organisms and unsimilar to material things.

I completely disagree with your analogy to a carpenter who builds a chair, this metaphor is wrong and responsible for a lot of misunderstandings when it comes to software development.

<comment><USER25> How about the words "fully baked"?

I also don't agree that "finish your program" needs to be added to the unix philosophy because a tool that does one thing and does it well is finished by definition.

<comment><USER24> Except very trivial cases, any piece of software contains bugs that need to be fixed needs to add features based on new user stories and also must to adopt to the constantly evolving hardware. Linux is a perfect example of this constantly evolving and never finished paradigm and if anything it can be used not to support but to invalidate the "finish your program" philosophy.

</comment></comment></comment><comment><USER26> > Imagine the carpenters were like programmers. You bought a chair. You bought > it because you've inspected it and found out that it fulfills all your > needs. Then, every other day, the carpenter turns up at your place and makes > a modification to the chair.

505 Bad Analogy. Carpenters work all the time on new designs and better chairs. When a programmer releases a new version of his program, it's like when the carpenter made a new chair and put it up on sale on Amazon or ebay (aren't these kind-of like package managers for physical goods?). You may want to buy that new one, but you may also not. Similarly, nobody forces software upgrades down your throat. But sometimes the people change, they want to sit on divans or nail-beds instead of chairs, the carpenters follow the trends and produce those instead of chairs, and people expect to find these when they come to visit you. You can say "sit on chairs or f*ck off!", but you can't avoid the consequences: loneliness. Similarly, you can hold on to your select programs in select versions, maybe backport patches for them, but the protocols change, the services change, world goes on. You may say eff-off and stick to your programs, but the consequence is that it'll become harder to share experiences and information with others, both ways. Nobody fixes or modifies your stuff should you not want them to, they may try hard to sell and bug you, but you always are the one that buys. Mobile phones do by default, but you can opt-out.

<comment><USER27> > _nobody forces software upgrades down your throat_

Windows 10 does, as does every SaaS web app out there.

<comment><USER26> But isn't that a bit like sitting on someone else's chair? You can't control things you don't own.

<comment><USER9> Yeah, I'd compare that more to living in a hotel, and coming into your room every day to find that _the hotel_ has replaced the chairs. The hotel, here, is the web service, or your OS's package manager

If you have a problem with constantly changing chairs, you're free to find a new hotel that doesn't do that—probably one with "LTS" in the name.

<comment><USER26> I was referring to individual software packages, an entire distro is a bit of a different beast. Going with the same chair analogy, well, you'd mostly care about the chair in your room, no? The one that you use the most. That's similar to what I do with Ubuntu (and any other OS): it takes care of all the programs except Emacs which I compile myself following master, Firefox Developer Edition which I'll use until 57 comes out, and my scripts and utilities that I've written. It's impossible to micro-manage every bit of software I directly or indirectly use, but it's a nice trade off to ensure the most important bits myself and trust the rest to the distro maintainers.

</comment></comment></comment></comment></comment><comment><USER28> > Please join me in my effort and do finish your projects. Your users will > love you for that.

Will they?

If your users are programmers, they _might_ love you for that.

For pretty much all other users, they will want more. "It would be great if your app did...". I would argue that users now _expect_ software to change and add more features.

And why wouldnt they, when pretty much all software they use is doing this? If your app isnt growing and changing, to users it way well look dead: "It's abandonware".

<comment><USER29> That's actually not my experience; I see people using "old" software all the time, and rarely looking for newer alternatives even if they feel that some things could be added or improved. As just an example, my mother still uses ATnotes - last released in 2005.

And I think the limited data we have shows that, like the number of people who upgraded their browsers before it was automatic.

<comment><USER30> And my experience is that there are many many combinations of some amount of both. I find a combination of both even with myself and sometimes even for a single piece of software! "I wish they'd add Markdown support!" "I wish they hadn't changed the UI!"

</comment></comment></comment><comment><USER31> > it's almost impossible to find anyting that's truly finished, not simply > abandoned.

This goes far beyond programming. "completeness" is nice but is highly subjective. For work that can be infinitely revised, refactored, recut, "finished" is an idea you impose from the outside, in relation to specific criteria.

The author seems to be saying that there is value in creating smaller, independent modules of things that can be said to be "finished" when they do their thing and no further functionality is added or expected to be added. Further functionality, if needed, would come from connecting "finished" things together, I suppose, or making new things- not over extending a component to handle all cases.

This moves the complexity around a bit and maybe it's more efficient and easier to handle this way.

Artists have a similar problem. It's hard to know when a poem or a song is "functionally complete" but eventually you have to let them go or you never get anything out there.

I'm all for conscientiously abandoning work, especially if the state of the work is well documented so that somebody else could, in theory, pick it up.

<comment><USER18> > This goes far beyond programming. "completeness" is nice but is highly > subjective. For work that can be infinitely revised, refactored, recut, > "finished" is an idea you impose from the outside, in relation to specific > criteria.

This is why I think a "definition of done" is so valuable on a dev team, especially in a startup environment. Without it, there's just natural inconsistency or variability across people and features.

</comment></comment><comment><USER32> The author implies that by releasing new versions of our software with security patches or features we somehow differ from construction where house are considered finished. They are not - there is a lot of maintenance to be done, painting, replacing pumps, sewage pipes, insulation, cables, I even had a house where we got a new balcony some 20 years after the house was "done", dito a completely new elevator recently some 40 years after finishing the house. I'm sure that if constructing houses had been as easy as rewriting software, we'd get a lot of other convenience changes just for the sake of being modern.

Software engineering is not flawed. It just lacks hundreds of years of experience which it will gain with time.

</comment><comment> rkuykendall-com > Imagine the carpenters were like programmers. You bought a chair. You bought > it because you've inspected it and found out that it fulfills all your > needs.

Then, every other day, the carpenter turns up at work and tries to improve how they make chairs!

Why can't they just stop changing how chairs are made? I like my chair, but I go back to the store after a few years and they're all different! Carpenters, finish your chairs. Those ideas you have? Stop having them. I like chairs how they are now.

<comment><USER33> That is how market works, people not satisfied with sitting experience and constantly trying to improve on that, yet QWERTY layout is still in use by 99.9%, it is enough to satisfy typing needs and good enough experience so nothing changes for ages.

<comment><USER15> > _That is how market works, people not satisfied with sitting experience and > constantly trying to improve on that_

Not sure if you're joking here, but if not - then no, it's not because of that. Companies jsut make new, "better" versions, market them hard, and are happy because when they pull the old ones from the stores, you have no choice but to buy one of the new ones.

</comment></comment></comment><comment><USER34> The reason this is an implicit principle of the Unix philosophy is because the Unix philosophy is to be as lazy as possible as the tool-creator and push all complexity onto the tool-user. Thus we get things like Go, regular expressions, and null pointers.

People outside this school of thought don't finish their projects because their projects actually try to solve the underlying problems in computing, which are inevitably hard.

<comment><USER35> Examples of underlying computing problems that are unsolvable if one follows the Unix philosophy? Keep in mind that it's often misunderstood what the primary tenets of the Unix philosophy are; your comment demonstrates you, too, have misunderstood.

<comment><USER34> What have I misunderstood?

</comment></comment></comment><comment><USER36> The difficult thing is to divide a big problem into a set of smaller ones that together solve the problem BUT such that those smaller solutions are valuable on their own, not only as part of the bigger solution that is your eventual goal.

So the problem is not so much to solve a problem but to FIND a problem whose solution is useful on its own and perhaps also as a sub-solution to bigger problems.

</comment><comment><USER37> I don't agree. The goal of software isn't usually to discover some perfect abstraction with nothing left to add and nothing to take away, the goal is usually to solve some practical real-world problem. If your software satisfies the requirements without taking too much time or effort to create, then it's a success.

If a project is going to be used by a lot of people or become some kind of industry standard, then it makes sense to spend some time up-front and figure out a clean interface and a well-defined feature set so you don't have to make non-backwards-compatible changes. It also makes sense to look at the feature set and figure out if you have the time and ability to complete those features, whether they're important enough to justify the effort, and whether there's an easier option that satisfies the requirement without having to boil the ocean. All this should be driven by the project goals, though, not some abstract ideal that all programs should be complete.

Some of the most useful software is going to be forever incomplete. Web browsers, CAD packages, operating systems, etc... I'm glad there are people working on software like that.

<comment><USER6> The author's point is not that there shouldn't be new systems or that no systems should ever change. He's not arguing for a perfect abstraction, either.

Following his development path (AMQP->ZeroMQ->nanomsg + libmill + others) his interest was in decomposing the larger system (AMQP which included message queues, databases for storing messages, wire protocols, etc.) into its smaller parts so that you could build back up to it in a better way. It happens that when you get to those lower levels, you can call them done.

If you're building a web browser, what's the proper scope for your project? Should it actually consist of all of these things in one project: tcp stack, http client, javascript interpreter, html parser and renderer, keyboard drivers, mouse drivers, touch screen drivers, etc.?

No. You build on the existing OS for the drivers. You build on the OS for the TCP stack. You may build an HTTP client, but odds are you can reuse an existing one, or the one you make could be partitioned off into a separate, and hopefully reusable, library. Your javascript interpreter can also be its own project/library. And most of that already exists, so you can focus on HTML parsing and rendering and glue in the other components. Your HTML parser doesn't need to know how to send an HTTP request, your renderer doesn't need to know it either. Only your browser needs to connect the HTML renderer and the HTTP client.

<comment><USER37> > Following his development path (AMQP->ZeroMQ->nanomsg + libmill + others) > his interest was in decomposing the larger system (AMQP which included > message queues, databases for storing messages, wire protocols, etc.) into > its smaller parts so that you could build back up to it in a better way. It > happens that when you get to those lower levels, you can call them done.

I think breaking things up into small pieces so that it's modular and you can work on one part at a time and then assemble a working system out of individually-testable working parts is a good thing (especially if you can re- use parts that other people have already made), but I don't think that's quite the argument the author was making.

I think the author was arguing that you should reduce the scope of the task any time you notice open-ended requirements with no clear completion criteria. I think that's good advice most of the time, but there are exceptions. It's okay to have a project that isn't "finished" if it's useful.

</comment></comment></comment><comment><USER38> What I love about games is that at some point they have to ship. They used to have to go in boxes. But even now that they don't, there is a still a date when they have to go live in stores. Deadlines terrify me and they create great anxiety in my life. But ultimately they are cathartic.

</comment><comment><USER39> I don't think the chair example is appropriate, because I think there are different, more comfortable chairs today than let's say a 100 years ago. So the "chairmans" are continuously improving the chairs, just not the one you bought.

</comment><comment><USER40> Software can be usable but 'incomplete', in the same way that stools and Aerons are both usable, but stools weren't an unfinished technology. If your bug count is low and your software has features, it's already done.

</comment><comment><USER41> Except that grep and make have continued to be augmented over time?

</comment><comment><USER42> Somebody has given up a significant amount of their time to give you something that's free as in beer and speech. You get at least what you pay for, don't ask for your money back.

<comment><USER43> The one thing you can _expect_ to receive in exchange for said significant donation of your time is recognition for your work.

If your work consists of half-finished code that you then attempt to pass off as a usable product, the expected reward is shunning.

There's a difference between pushing your CS101 homework to github and publishing your package to npm. As with academia, once you publish you implicitly vouch for the quality of your work, and your reputation is permanently tied to it.</comment></comment>


What I think about RMS's hatred of closed source - <AUTHOR> http://www.cafepress.com/linuxhatersblog.283165091

<comment><USER2> That's... quite tasteless, really.

I believe JWZ was the first to link to the Free Software Song with the text [why cooperation with RMS is impossible](<http://www.gnu.org/music/free- software-song.html>), expressing a similar sentiment with more erudite snark.

Although I agree he can be difficult to get along with, I appreciate the movement he began and benefit from it daily in the form of Ubuntu and Fedora, so no complaints from me.

</comment><comment><USER3> If you have "thoughts" about RMS, kindly post them in a relevant thread instead of abusing the submission system.

FLAGGED

</comment><comment><USER4> At least RMS probably knows that the command is "gunzip", not "ungzip".</comment>


Avoiding Double Payments in a Distributed Payments System - <AUTHOR> https://medium.com/airbnb-engineering/avoiding-double-payments-in-a-distributed-payments-system-2981f6b070bb <comment><USER2> ive been thinking of this problem a lot recently and this is good but I wonder how a given service (of which there could be many replicas of said service) finds its idempotency key. If I take a key / generate a key and then crash, how do I find my key again? I assume they do something simple like have a unique service identifier ie service-name+replica# and use that for querying for a particular key.

they mention using a deterministic key for this kind of problem but that can be tough too

<comment><AUTHOR> For some things it is relatively easy. Charging for a booking would include the booking id and the amount, perhaps even the credit card number. This allows the customer/seller to hit charge multiple times but it will happen only once.

But more importantly, as far as I can tell, the ID generation happens in the preRPC phase and is commuted to the database. The RPC call is only done after the ID is persisted so if any crashes occur the pre and post logs can be automatically reconciled.

This system looks a lot like a combination of command and event sourcing with a nice library for putting the right actions in pre, rpc, and post.</comment></comment>


The 5 ES7 Decorators I want to use, now - <AUTHOR> https://medium.com/@zackargyle/the-5-es7-decorators-i-want-to-use-now-ca40d1d5c114

<comment><USER2> Fair enough, good suggestions. But if the writer wants this _functionality_ , as opposed to just the syntax, they can all be written right now. So why the desire for this to be a thing?

It's always been one of the strengths of languages with functions as first class objects that 'decorators' are a core part of how you build code. I get that some people find it odd, and prefer a special syntax, but I do worry that more syntactic sugars just serves to further remove new programmers from actually understanding the language.

I'm on the fence about having 'classes' in Javascript, that aren't actually classes. Will it make it easier for new programmers to get productive in Javascript? Maybe. Will it make it harder for developers to get to the modus ponens and really understand the language? Yeah, I think it probably will.

<comment><AUTHOR> I totally understand what you are saying. In fact, I wrote another blog post about how AngularJS is turning new devs into javascript zombies. For me, writing code is always about eloquence. How can I most eloquently write this so that it is understandable and DRY. I see decorators as a win for this.</comment></comment>


Doomsday bunker companies enjoying big increase in business since pandemic began - <AUTHOR> https://www.nytimes.com/2020/06/26/realestate/could-doomsday-bunkers-become-the-new-normal.html <comment><USER2> Use care when considering these companies. I have been researching these for a couple years now, and thus far I have seen some pros and cons. I won't name names.

Pro: They can help you with getting permits and they are all-in-one for some features you would expect. If you just need a fairly quick installation of a safe room for your family to evade a tornado or hurricane, these are probably the quickest path if you have $100+k laying around.

Con: They are super expensive and you are paying a premium for not getting a local engineer to draft a plan and custom build a solution for you. These pre- built containers are small and meant for short term usage. Their air filtration systems are extremely expensive and yet still noisy. Their generators are noisy and too close to the living quarters. They are not designed to protect against civil unrest, as attackers can block / lock you inside. They assume ground level is not a flood zone, so you have to ensure that all water will run past your hatch. I mention this because even their own videos show them building in flood zones. They have a ladder and hatch which is not compatible with the elderly. You need to plan in advance for conduits, welding and wiring for solar panels. The hatch is very small, which means equipment has to be broken down before installing or replacing. Adding things after the installation is completed may be problematic. Their sales people are very pushy and make aggressive videos trying to take down their competitors. Each claim to have a secret sauce which is a warning sign to me. This suggests they are not following best practices that military bunkers have used for many decades.

In my opinion, it might be better to research this well in advance and look into existing plans created by people that have built "earth ships" and other environmentally friendly geothermal optimized homes that are either partially or completely under ground. There are thousands of videos on youtube of people that have done this for about the same cost as these all-in-one solutions that provide more living space, storage space, less dependency on generators, and the list goes on. You may even be able to get a grant in some locations to offset the cost of an earth ship.</comment>


Turn on satellite view and zoom in to 26.357865, 127.783782 - <AUTHOR> http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=26.357865,+127.783782&aq=&sll=53.800651,-4.064941&sspn=12.478806,28.256836&vpsrc=6&ie=UTF8&ll=26.357862,127.783785&spn=0.001154,0.001725&t=h&z=19 <comment><AUTHOR> This probably isn't, of itself, worthy of HN, but it made me wonder - is there any mileage in having a site that gathers together these sorts of links?

There are zillions of "amusing" sites out there, perhaps they in turn need a meta-index. It just feels to me that there is a market here for a sensible, reasonable site that has stuff that's more interesting than the usual stuff people tout as "OMG!!! FUNNIEST PICTURE EVER !!!11"

(Yes, the 1s are intentional)

<comment><USER2> _is there any mileage in having a site that gathers together these sorts of links?_

Though I don't know of any offhand and am too lazy to search on Google, I have seen sites with collections of interesting, cool or weird things on Google Maps and Google Earth. I'm sure you can find them if you search a bit.

If you mean links of interesting stuff not just Google Maps/Earth stuff, then.. perhaps Reddit (or a subreddit)?</comment></comment>


Two full stack hackers, first time in SF, we'll buy you coffee. - <AUTHOR>

We're two full stack hackers currently working at Testive (Techstars Boston '12).
I work marketing (CS major at school) and my friend is a developer (Chem major at school).
We're making our first trip to SF and would love to buy you a cup of coffee to meet with you / discuss careers/startups. We're here to check out as many different companies as possible and get a feel of Valley culture.
Please let me know: arjunblj [at] gmail .com! <comment><USER2> Good for you for reaching out. You should provide links to your backgrounds and projects and maybe expand on your interests.</comment>


Complex memory corruption techniques – heap metadata and AddressSanitizer bypass - <AUTHOR> https://github.com/ewimberley/AdvancedMemoryChallenges

<comment><AUTHOR> Feel free to ask questions here, but be careful not to post spoilers.</comment>


The making of Dark Castle - <AUTHOR> https://www.gamasutra.com/view/news/315720/The_making_of_Dark_Castle_An_excerpt_from_The_Secret_History_of_Mac_Gaming.php <comment><USER2> That article was pulled from book "The Secret History of Mac Gaming" which is full of same quality of research from same author.

You can get the digital version here - [https://unbound.com/books/macgaming/](https://unbound.com/books/macgaming/)

Or looks like you can buy on Author's site via Amazon here -

[https://www.amazon.com/Secret-History-Mac- Gaming/dp/17835248...](https://www.amazon.com/Secret-History-Mac- Gaming/dp/1783524863/)

I was an original backer of the project, no other affiliation very cool to see it on HN and highly recommended the book is a beautiful piece!

<comment><USER3> I assume he must talk about Ambrosia SW, right? If so I might have to get it, I've always wanted to know more about them, especially the development of the Escape Velocity series.

<comment><USER4> Yep. From the above linked page, interviews with:

Andrew Welch (Ambrosia)

Ben Spees (Harry the Handsome Executive, Ferazel's Wand)

Matt Burch (Escape Velocity)

Also:

Alex Seropian (Bungie)

Eric Klein (former Mac game evangelist, Bungie)

</comment></comment></comment><comment> jonah-archive Playable in-browser over here at the Internet Archive: [https://archive.org/details/mac_DarkCastle_1_2](https://archive.org/details/mac_DarkCastle_1_2)

An article about that collection: [https://www.theatlantic.com/technology/archive/2017/05/mac-a...](https://www.theatlantic.com/technology/archive/2017/05/mac- attack/527979/)

</comment><comment><USER5> What a great game! I played this for hours back when it was released and I did finally make it to (and beat!) the Black Knight level. So many good memories. IMO, the difficulty level was much closer to today's tougher indy games.. Not sure I'd have the patience today.

Beyond Dark Castle was fun too, but it was way more sprawling and confusing. DC was just a compact, tight, totally winnable game. Loved it. It being in black and white was not an issue, either. Given the mood and subject, it totally fit.

The vertical blanking hack is real typical of Mac software of the era. There were a bunch of things that low-level devs had to use it for, but you had to be careful, as it didn't last very long.

</comment><comment><USER6> Mark Pierce's Super Happy Fun Fun did release an amazing game called Return to Dark Castle: [https://itunes.apple.com/us/app/return-to-dark- castle/id4107...](https://itunes.apple.com/us/app/return-to-dark- castle/id410703154?mt=12) It runs on modern macs, is tremendously faithful to the original, recreates all levels from the original and the sequels, and adds some new levels (I think).

Also, at an amazing price!

<comment><USER7> 50 new levels.

Price is $10, which I'll say is fair... but not exactly amazing.

<comment><USER6> Interesting. I bought it when it was $20 and felt it was well worth it. I was worried when they dropped the price to $10 about the company going out of business.

I guess there are probably better deals out there, but I'm happy to pay $10 for a game this well-done that provides this many hours of entertainment.

I'd hate to see good games like this disappear because there are too many free ones on the app stores and people don't want to pay for games anymore.

</comment></comment></comment><comment><USER8> An easter egg that I fondly recall finding: If you ran the game on December 25th, the suit of armor in the entryway is replaced with a Christmas tree.

</comment><comment><USER9> It's striking to me to compare the state of games in 1987 on the Mac (as depicted in this article) and on the Amiga:

[https://www.google.com/search?q=amiga+game+1987](https://www.google.com/search?q=amiga+game+1987)

It doesn't even look like the two computers are of the same generation.

<comment><USER10> Dark Castle was 1986, but your point stands. But 1987 was the year the Mac II came out, with excellent color graphics support. It just took a while for developers to support it.

<comment><USER11> When the Mac II came out it cost $5500.

The Amiga cost $600.

Sources:

[https://en.wikipedia.org/wiki/Macintosh_II](https://en.wikipedia.org/wiki/Macintosh_II)

[https://en.wikipedia.org/wiki/Amiga_500](https://en.wikipedia.org/wiki/Amiga_500)

</comment></comment></comment><comment><USER12> Wow, hadn't heard the name "Dark Castle" in eons. That was a pretty good game, but as someone who has pretty much sucked at platformers forever, I could never get very far in the game.

The game I probably ended up played the most on my Mac of that era was Canfield (solitaire).

</comment><comment><USER13> Ah, the early days of PC gaming - where one kid could program the most popular game and make a fortune off it without Apple/Steam/etc taking all the profits in an commoditized market of games; but also where they had to be written in assembler by hand, a single PC would cost your life savings, and distributing a game could require a (third) mortgage on your house... They were interesting times, but as a consumer I definitely prefer now.

<comment><USER7> Can you name an example of a child video game prodigy who made millions making a game by themselves?

I knew that it was much easier to make a fully formed game as an individual developer back then obviously, but I've never heard of anyone who profited from it like that. I thought independent developers were much better off today with the ability to make a game like "Flappy Bird" and have it distributed and advertised for you by companies like Apple.

<comment><USER13> I seem to recall seeing a number of examples on filfre.net, and other games like _Prince of Persia_ were largely one-man jobs (he got some help with animation and whatnot, but it was essentially a one-man thing, judging from the famous developer diary). One problem is that people don't always cite exact dollar amounts, and when they do, they don't inflation-adjust - if you made 'only' $300k off a computer game in 1980, well, that's a million dollars now right there.

</comment></comment></comment><comment><USER14> My mum would try to stop me playing this because it was too violent. The prisoners getting whipped in the dungeon really apalled her. Violence has come a long way since then.

<comment><USER15> I must admit that I stopped watching this video at the scene where the prisoners are getting whipped because I found it upsetting. I watch Game Of Thrones and have played violent video games. So I'm not your Mom. :)

Perhaps the audio is just too clear ? Or perhaps there isn't enough going on scene-wise to distract. Or just the fact that the whipping is perfectly periodic and programmed to go on indefinitely. I don't know.

</comment></comment><comment><USER16> Dark Castle and Beyond Dark Castle were astounding to me as a kid. Sounds like they had a great team.

</comment><comment><USER17> I remember sitting with Charlie on a boat in SF Harbor during the first Apple WWDC (called something else) in 1986 listening to how they did the audio. He was definitely an inspiration to us younger Mac developers.

</comment><comment><USER18> This was my one break during the year of my honors thesis! Once a week on Sunday morning I would stop work and play Dark Castle for a couple of hours. Good times!

</comment><comment><USER19> If you like this, Jordan Mechner did a great series of journals about the making of Prince of Persia which you can buy in book form and I think also read for free on archive.org

</comment><comment><USER20> That ending was spectacular.

>international style rapid-fire pistol shooting

and he made the team!

My startup partner will likely take his earnings and realize his dream of owning a club (adult variety) should it ever take off. I just want a jet (small like HondaJet).

</comment><comment><USER21> Oh man I loved this game. Playing it on my Mac Classic felt magical.

</comment><comment><USER22> TIL Jonathan Gay is a cattle rancher now.</comment>


How I Learned Enough Ruby On Rails In 12 Weeks To Launch Freelancify - james-fend http://www.webstartup.me/learned-ruby-rails-12-weeks-launch-freelancify

<comment><AUTHOR> Congrats on the launch. I think I speak for everyone on HN when I say, you're going about this the right way: learn enough to build applications for yourself, whether or not you're going to be a code committer over the long term.

Can I give you some quick advice? Don't take this the wrong way: Rails makes it easy to learn enough to be dangerous in 12 weeks. Some quick hits on obvious things you should look over in your application to ensure it isn't overtly insecure:

* Every model class should have an "attr_accessible" statement, and the attributes you expose through it should be minimal. A very common misconception: "the things in attr_accessible are the only attributes users can set". Not so! The things in attr_accessible are the only attributes users can set _automatically, through mass assignment_. You can expose things that aren't in attr_accessible by manually settings them with assignment statements. Assume anything that's in an "attr_accessible" list, and _every_ attribute of a model without attr_accessible, can and will be set to the most hostile possible value, like "role=admin".

* Rails programming intros have a bad habit of introducing ActiveRecord finders in the context of the model class object --- in other words, "Post.find(params[:id])". This is exactly the wrong way to do it; it's so bad that you can literally generate a list of vulnerabilities on Rails projects by grepping app/controllers for "[A-Z][a-z]+]\\.find". Instead, make sure all your finders work via associations, like "@current_user.posts.find(params[:id])".

* Use a popular plugin for file uploads. Rails doesn't do much of anything to defend against file upload/download vulnerabilities. If I was building a public-facing Rails application, I'd do whatever I could to keep the filesystem namespace out of my requests --- storing all files on Amazon S3 without explicitly storing them in temp files is a good way to do this.

* Don't enable the old-style wildcard route ("/:controller/:action/:id) or any of its variants ("/posts/:action/:id :controller => :posts); whether you declare methods "public" or "private" in a controller should have nothing to do with whether they're exposed to attackers.

* Have a "PreauthController" that inherits from "ApplicationController" and _disables_ the is-logged-in check; in other words, every controller, particularly every controller generated by "rails generate", should be post-authentication _by default_. Set up the before_filter that checks for a valid user session right there in ApplicationController, then "turn it off" for the LoginController by having it inherit from PreauthController. Similarly: if you can get away with not having an AdminController at all --- run a totally separate Rails app for admin that requires a VPN to get to --- do that; otherwise, have an abstract AdminOnlyController class with no methods in it that does nothing but set up a before_filter to check for admin privileges, and have every admin-only controller inherit from it.

* Pretend the backtic operator (the one that executes Unix commands) doesn't exist.

You may do all of these things already (in which case, good for you! you learned more in 12 weeks than a lot of Rails developers do in years). I just called them out because (a) not doing them will be tremendously painful down the road (individual XSS slipups are annoying but unlikely to kill you, but vulnerabilities that allow people to dump your whole database are something else) and (b) they are so easy to fix.

Good luck!

<comment><USER2> Teaching good security practices was one goal of the _Ruby on Rails Tutorial_ (a resource mentioned in the OP). It uses attr_accessible for _every_ model and uses find-through-association (emphasizing the security implications of both), and it most assuredly does _not_ use the /:controller/:action/:id pattern or backticks. It punts image upload over to Gravatar, and recommends Paperclip for those who need custom uploads.

Having a PreauthController definitely sounds like a good idea, but it might be a bit obscure for beginning developers. I'll consider it for inclusion as an exercise in one of the chapters covering authorization, or maybe I'll include it in more advanced _Rails Tutorial_ material down the road. Thanks for the tip.

<comment><AUTHOR> All I can say is, I looked under the hood at the application we're talking about and thought these might be useful suggestions. Particularly attr_accessible.

I've found a lot of Rails apps over the last couple years that were diligent about _having_ an attr_accessible in every model, but not diligent about what went in the attr_accessible. Following the Rails idiom, they were doing all their attribute assignment through update-style params[:model] model[foo] model[bar] stuff, and attr_accessible "breaks" that.

The Rails tutorial is good (and ambitious) --- just know, this stuff trips up solid, experienced Rails developers all the time.

<comment><USER3> When I was starting out, every tutorial seemed to assume that I even knew what "mass assignment" implied. Creating a bunch of bad things at once? Changing a lot of existing things in a bad way at once like their creator_id so a bad guy could access them?

I think "mass assignment" and "attr_accessible" in tutorials should always link to the API documentation[1] that explains the implications and the tools at your disposal + example code.

[1]: [http://api.rubyonrails.org/classes/ActiveModel/MassAssignmen...](http://api.rubyonrails.org/classes/ActiveModel/MassAssignmentSecurity/ClassMethods.html)

<comment><USER4> Worse still, I started off with _Beginning Rails 3_ by Apress, and it makes only one obscure reference to attr_accessible, and not in the context of security, doesn't mention mass assignment at all, and has no chapter on even basic security. Beginners need to learn this stuff early, so Apress' oversight is unforgivable. mhartl OTOH is to be applauded.

</comment></comment></comment></comment></comment><comment><USER5> The other thing I want to add is how much 'else' I learned while running through Michael Hartl's tutorial.

Despite many years making websites, I really had no clue about basic http methods — get, put, post, etc — and in fact, I didn't even realize what they were. The other huge, huge thing for me was finally figuring out what REST is all about.

Basically, the web runs on those few basic http methods, and using the REST approach spells that out for you and cements it in your head.

I had an awesome jump-up-and-down moment when it finally clicked.

<comment><USER3> And 'else' things like Git, actually working with Github and Heroku, and learning how to test in the same tutorial that's teaching you Rails.

</comment></comment><comment><USER6> I get really annoyed when there is an element that follows me down the page as I scroll. It's really distracting. I get even more annoyed when I have to set up an adblock rule to make it go away.

Please, designers, stop doing this (and stop doing menu bars with the same behavior). There's not much on your site that is important enough that I need it to follow me everywhere.

</comment><comment><USER5> Fantastic post. Thanks so much for it. I decided to really dig into Ruby on Rails after Christmas this year, after thinking/talking about it for years. I was thrilled to hear that you really had no programming background—I think a lot of us are in this boat.

I watched the Lynda.com videos on Ruby, and the one on Ruby on Rails (both from Kevin Skoglund). I just watched enough of both to get fairly overwhelmed and confused, then moved on to Michael Hartl's site. Things started to click much better there—that's the best Rails resource I've seen to date.

Still though, After really digging in over the evenings and two weekends, that nagging feeling started to set in—am I actually going to 'get' this? Am I wasting my time? Is this going to take years? Will I ever get past layouts/partials? Should I just go learn PHP / Javascript / iOS / something else?

Did you feel like giving up? Or question the purpose/wisdom of learning Ruby and Rails?

<comment> james-fend Yes, it was the hardest/easiest thing to learn I've ever experienced. Sometimes I was jumping out of my chair and then other times throwing things against the wall.

Plenty of times I wanted to just give up.. during those points; I'd step back and go take a break, go for a walk, do something.. other than think.

Programming is hard because it's full-time blitz mode thinking. I felt the front part of my brain (is that where all the programming juice is held?) hurt often in the beginning.

Do you have an actual product you want to work on?

<comment><USER7> I'd like to add to this simply because I had a very similar experience but with PHP.

There were definitely times when I was extremely frustrated and wanted to give up. There were a couple times when I had 5+ hour sessions and got nowhere, then I'd come back the next day to realize it was a stupid mistake.

One thing I can't stress enough (and James has been saying it too), if you don't have a final site, product, or app in mind you're probably going to get bored and walk away for good. I tried to learn C++ a while back and gave up because I didn't have anything in mind and the boring repetitive exercises lead to nothing in the end.

<comment> james-fend "then I'd come back the next day to realize it was a stupid" I couldn't agree with that more!! Come back and you find out all you had to do was restart the 'Rails Server' or simply mis-spelled something.

</comment></comment></comment></comment><comment><USER7> Great write up. I experienced a similar adventure in learning PHP over the past couple months and I completely agree that the first few weeks are by far the hardest.

Late last summer a friend and I came up with a great idea but we lacked the programming skills to create it ourselves. I knew a bit of HTML, a touch of c++ , and PLC ladder logic programming(huge help, right?). It wasn't until around October that I realized we were getting nowhere. I decided enough was enough and I was going to learn how to program. I spent an entire weekend reading and trying out zend's PHP 101 for beginners. Three months later and I had created a user authentication system with messaging, friends lists, administrative rights, and all sorts of other goodies. I was working a full time job so I did this with my spare time.

Your site looks great by the way. Keep up the good work.

<comment> james-fend thank you! how many hours total do you think you spent during the 3 months?

<comment><USER7> During the initial learning phase I wasn't as enthralled because who cares what $this->someFunction($variable) means? I'd say I put in around an hour per day for the first month and then once I got the hang of it, probably 2-4 hours per day after that. I made sure to take off programming at least one day per week so I wouldn't get burned out considering I was working full time too.

So, I'd estimate around 150-160 hours. I should've kept track. I plan on learning ruby later on this year and I'll be sure to keep a record of that.

<comment><USER7> James, this is in response to what you said to my last comment. The reply button wasn't showing.

Anyway, that 150-160 hours was to the point where I was comfortable enough to sit down and code away. I'm still working on the system and I'm still learning a lot. I'd also like to become a lot better with css/jquery. I know the basics and not much more. A guy on my team is a front end whiz so I don't have to worry about cramming that into my head right now.

</comment></comment></comment></comment><comment><USER8> Hey James, very inspiring read. I've been following your story and progress on the fastlane forum and glad to see that you had a successful launch! I've also been learning to program myself but my language of choice was python and django for framework. You are right that it takes some time to get through that initial learning curve but once you reach that first stage and figure out how to get past everytime you get stuck, it gets pretty exciting and fun. Congrats and best of luck to you!!

</comment><comment><USER9> Any advice for getting started for someone without a Mac? I remember once trying to learn and immediately stalling out during setup (lame, I know). I have WinXP & Ubuntu, and would like to take a stab at this again no matter how stupid I feel about not even being to able to install the damn stuff to start with.

<comment><USER10> Use Mac Leopard, and don't switch from 32 bit to 64 bit - you're gonna get a massive headache getting all those gems you need to install. Also if you're considering doing anything to do with image processing, consider NOT using Mac. Installing stuff like PIL and ImageMagick can be hell

<comment> james-fend Using MacPorts to install ImageMagick was hell. But when I used HomeBrew, it was like night and day.

</comment></comment></comment><comment><USER11> I just had a look at Freelancify and registered, and I'm amazed that you did it all in 12 weeks learning Ruby from scratch. Kudos!

Based on your experience, how do you think learning materials/tutorials could be improved for people learning from scratch?

<comment><USER12> I had a look at it too, and from a design standpoint it looks very nice. I am not sure about your choices for project budget. For example, this description was posted for bids:

 _Need Drupal developer to: - do PSD/HTML to Drupal theme for one new section on the existing site. - Do additional module programming. - fix issues/error on the site - Make the entire site work_

With a stated budget of $100--$300. I mean come on, that's ridiculously naive on the part of the person who posted. If you could give bid-seekers some guidelines on what to reasonably expect, e.g. some examples of what a budget of $100-$300 might buy, it would help people get qualified bids.

</comment></comment><comment><USER13> Awesome work, James!

Your site looks really nice, and now you've got the ability to do design AND program, which is a combo that isn't too common.

Best of luck with your site....

</comment><comment><USER14> XSRF: [https://github.com/evanlong/security/blob/master/web/csrf/fr...](https://github.com/evanlong/security/blob/master/web/csrf/freelancify.html)

<comment><USER15> Doesn't the rails csrf token prevent that?

</comment></comment><comment><USER16> Fantastic and inspirational writeup. Definitely will be forwarding the story to my nephew who is starting to show interest in programming.

</comment><comment><USER17> thanks james and commenters saltcod and tmh88j for saying that the first few weeks are the hardest. I'm banging away at the google python exercises and nearly crying. knowing that other people are going through this headache too gives me a bit of confidence to truck through.

<comment><USER7> Once you get through the basics, think of a couple small programs to write to test out your new skills and you'll be sure to encounter new problem. Some of the first programs I wrote in PHP included sorting and ordering a list of numbers and letters that were entered, a pig latin converter, and then to get the hang of MySQL, I created some simple database entries.

For the first month I was constantly referencing other code online to figure out how to create my programs. After a while I found myself looking less and less at existing code and I was able to simply type away.

</comment></comment><comment><USER18> James, I'm kinda in a similar situation like your old-self and now you have a gun.

</comment><comment><USER19> Did you go about this project doing TDD/BDD?

<comment><USER20> No, sounds like he used PM [1].

1\. <http://programming-motherfucker.com/>

<comment><USER20> If I could edit that, I'd add a smiley or something to make it clear I didn't intend to be an ass. Meant that to be funny.

</comment></comment></comment><comment><USER21> As someone with programming background, I actually wish there are more stories on the opposite direction (programmer who gets kickass awesome in UI design (HTML + CSS)).

I think that the complexity of CSS compatibility (what browser supports what not... even there are minor quirks between Firefox & Chrome, not just IE.. don't get me started on IE7 & 8 either), it is very easy to raise a white flag and say "that is it..I am going back to deal with backend only tasks, nothing that consumer will see on the surface).

Perhaps, OP already has a knack for UI design (as he/she mentioned in the post that he/she is a UI designer by trade before Ruby), so kudos for getting a nice grip on Rails. As for me, I wish I can master the UI design etc.

<comment><USER22> I sort of built my skills in unison (had an interest in both programming and design since I was a kid), but my career has tended towards the development side, so I guess you could say that I am a programmer by trade that picked up design on the side. Whether or not I am "kickass" is subjective, but people seem generally happy with my work.

The biggest challenge I find is that people do not take designer programmers seriously. Those who do just enough programming to support their interfaces seem to be respected, but as soon as I dive in writing some low level component in C, as an example, my design skills are immediately discounted, it seems.

Programming _is_ design, in my opinion. The way you structure your code, getting the indents and spacings just right to be pleasing to the eye, are the exact same skills you need when you're shifting pixels in photoshop. Thinking about how the next programmer will interpret the meaning of your code is the same skill you need when thinking about how a user will use your interface. I feel the only thing limiting a programmer from becoming a good designer is practice.

<comment><USER23> I have the opposite background, but similar anecdotes. Spent all of high school and college in various art or design-focused curriculum and degrees. Inevitably ended up taking a few dev courses, but was only marginally interested. My first job after college was as a web designer in a software shop where I quickly realized that "real-world" programming mixed aesthetics and creativity with logic and really hard problems, was immediately hooked and started absorbing everything (even SICP!) in my quest to become a better developer.

Like yours, my left-brain intuitively sees patterns and (un)readabilty in code, beauty in simplicity, and has empathy for users/novices. My right-brain solves the problems, connects the top to the bottom, and is cold-and- calculating about the inner-workings.

It's also my experience, that if you are design-forward people discount your programming skills (all the more reason to prove them wrong) and if you are development-forward people discount your creative side ("oh, I _totally_ trust your opinion, but just to be on the safe side....").

IMHO Diversity of skills gives you insight into your work and the world around you. Even if you are not a natural you still gain new perspective. Hell, even knowing that you aren't any good is half the battle! I am good at _executing_ other people's ideas, and intuitively knowing what looks good - but struggle coming up with an original _truly unique_ artwork from scratch. On the other hand, Give me an empty vim buffer...

</comment></comment></comment><comment><USER24> I can't get the tryruby.org site to work properly. If I do anything wrong it just locks up and I have to refresh the browser window.

For instance at the "type 2 + 6" question, if I type 2+6 it freezes. If type 2 + 6 it's fine.

Running OSX Lion and Google Chrome.

Dave

</comment><comment><USER25> is this a joke? if so its funny... when i click the link i get: "Error establishing a database connection", haha

<comment><USER26> It's likely a result of a cheap host server not being able to handle the traffic. Not a reflection of OP's programming abilities.

<comment> james-fend Yep. That's exactly it, it's on a cheap server and too much traffic. Anybody experience this before and/or know some quick solutions?

<comment><USER27> You mentioned Heroku in your post. Why did you decide not to host there?

<comment> james-fend Good question. The wordpress blog (webstartup.me) is on a cheap server. Freelancify is hosted on Heroku.

<comment><USER28> jekyll on S3 is a pretty killer combo for a cheap blog that scales infinitely and automatically. You'll probably like it, especially since you're a ruby guy.

<comment> james-fend thank you for the suggestion, will look into that. The popularity of the posts def caught me off-guard..</comment></comment></comment></comment></comment></comment></comment>


Learn Genetics - <AUTHOR> https://learn.genetics.utah.edu/ <comment><USER2> Commenters here are noting many ways in which CS and biology are different, and how computer analogies can break down.

I've got a PhD in biology, and have been into computers all my life. I write code as a biology researcher every day.

To me, there's a much more practical level to this than that of philosophical questions on how far analogies take you. Biologists and computer scientists learn, in their studies and through lots of experience, a different mindset about how things work.

As a computer scientist, finding a solution to a problem, or predicting how a system will behave, is ultimately just a question of having a deep knowledge of the system, plus being a little bit smart about using that knowledge.

As a biologist, having a deep knowledge of what you are dealing with plus being a little bit smart is just a starting point for formulating hypotheses that you will then still need to test. Every biologist knows in their gut that a plausible story is ultimately just that. It's not a proof of anything, just a starting point.

This runs really deep and can make communication between people who aren't aware of this difficult. I see this in comments here all the time, where someone has read up on a little biology, and then goes on to explain that, therefore, clearly this or that has to be true. Usually that makes me go: "Yeah, maybe. But what about all these other things you didn't consider? And what about all those things that literally no one in the world knows you would need to consider in this particular case?"

Anyhow, I think it's still productive to try to find simple physicsy explanations in biology. Sometimes it does work, and then you get things like PCR or gene editing... ;)

<comment><USER3> Are you willing to consider the opinion that CS people can make a similar mistake with out of field problems as people with a PhD in Biology make about CS problems?

<comment><USER4> (DISCLAIMER: The following is based on my own experiences and may not agree with your own. These are just things I've personally observed to be true. And of course these are just tendencies rather than absolutes.)

Do you often see biologists without CS backgrounds making those kinds of mistakes about CS topics that people with CS backgrounds make about biology topics?

I also have a background in CS and biology, with some math and physics, too. I've also observed the tendency of people mainly trained in formal sciences (e.g., CS, math, logic) who's schooling involves a large amount of deriving things from first principles, to make this mistake (this is also true of more mathematically inclined physics majors and certain flavors of economics majors). They often think that what they know is enough to derive a novel insight from first principles, when the further you get from physics, the less true that becomes as the nonlinearity and sheer complexity of the world starts to interfere.

Different areas provide different ways of thinking with different strengths and weaknesses. They aren't mutually exclusive in the sense that learning one makes it harder to learn the other, but they require a non-trivial depth of study to pick up so most people tend to get mentally siloed unless they either study one of those other fields or somehow pick it up through a more non- traditional route (which absolutely happens, but is less reliable).

If you want an example of the type of things biologists tend to be weak at, I'd say quantitative thinking (at least relative to other sciences). Biologists tend to be the most math-phobic of the natural sciences, so most have a mental ugh field around most math. You'd be shocked how many grad students can't do some fairly basic stuff. Many undergraduate programs barely require calculus, though that's slowly changing, and you'll often get some exposure to some elementary probability and combinatorics in your introductory genetics class. And it's shocking how many people with whom I studied evolution and comparative physiology and anatomy didn't come away with some degree of probabilistic intuition.

Other fields I've studied to variously minor degrees that train particular mental habits or develop particular skills and perspectives that I've found valuable are psychology and the study of cognitive biases, cognitive science, computer programming and software engineering, chemistry and biochemistry, literature, economics (both the traditional kind and the more modern behavioral kind), probability, game theory, history, anthropology and a few others.

Fields I suspect train other mental habits/skills/etc. that I lack and haven't yet studied include poetry, martial arts, dance, jazz and/or improv, music theory and music in general, drawing, deeper dives into the topics I've already encountered, and probably a ton more that I'm can't remember.

Really the more wide ranging your curiosity is, the more well-rounded you become. And since most people don't bother leaving their silos (maybe a handful of others at most), you can after many years start to put together all sorts of insights that others find non-obvious (though they will still rarely be novel).

(I think nowadays people might call these "mental models", but learning about mental models directly through a description in a listicle has always seemed less useful than studying the fields themselves and indirectly building the mental model yourself.)

<comment><USER5> As a bioinformatician, while I largely agree with you, it's worth nothing that it's not that biologists are math-phobic or bigoted about the value of numbers - it's that biology has undergone the most radical changes in recent years of any of the primary sciences. A helpful metric (perhaps apocryphal) that I heard at a talk is that the total amount of knowledge in the sciences doubles about every 10 years, in biology every five, and in genetics every two years. Most biologists working today were trained before the genomics revolution, and have not developed the mental heuristics around it. In comparison to today, the genetics of 25 years ago feels practically paleolithic, and it's a comparison this stark is hard to find in any of the other sciences. Genomics in the early years was also an unregulated Wild West, with lots of speculative studies and predictions that never panned out. The field matured rapidly, but as a consequence experimentalists are vary of "predictions". For example, despite intense scrutiny, about a third of E. coli genes remain uncharacterised, and we don't even know if they're really genes, or an artefact of the gene prediction process. As a bioinformatician, the barrier to entry for predictions is quite low, and experimentalists are understandably cautious. It's also a case of moving goalposts - they get used to and begin to accept computational predictions from one domain, and meanwhile whole new fields of computational biology have opened up. It'll take a while for them to accept them.

<comment><USER3> Sounds like a great time to be alive!

<comment><USER5> It is! If you look at some of the brand new labs being established by freshly minted assistant professors, many of these fields didn't even exist 5-10 years ago. Machine Learning has just begun to percolate into Biology, and we are on the verge of major shifts in the field.

It's also not just computational biology that's booming. Another of the fields I follow, population genetics, has been practically rewritten in the past decade, thanks to improved techniques extracting Ancient DNA. When I started my PhD, the idea of extracting and assembling the genome of a Neanderthal was a distant pipe dream. By the time I finished my PhD, we have multiple Neanderthal genomes from across Eurasia, and the discovery of a previously unknown human ancestor, sequenced entirely from a single finger bone in a Siberian cave.

</comment></comment></comment></comment></comment></comment><comment><USER6> This looks like a pretty awesome resource. I think it's well worth it to spend some of your quarantine time on learning the basics of the biology you need to know to understand what's actually going on with the virus that's the reason you're in quarantine in the first place. It's not super productive to try and understand this stuff through analogy to computers and algorithms. Assuming DNA works just like code amd that cells are biological computers turned out to be a very poor assumption indeed, as evidenced by how much less we understand after sequencing the human genome compared to what we thought we would have known. It's also why the secrets of the coronavirus didnt reveal themselves immediately after sequencing it's genome. See the epigenetics section for a bit of an understanding of the layer of complexity that lies on top of DNA, and let's take a moment to appreciate the biochemists and the protein biologists unraveling what makes SARS-COV-2 tick.

If you want to really grok genetics and be able to understand and interpret news and discussion about the field, especially considering how important the field is in our day to day lives, both with the virus and with biotech/medicine in general.

<comment><USER7> I am from a computer science background. I understand basic biology and genetics. I have been trying to understand what are reasons why code and that cells are biological computers is a poor assumption. Anecdotal evidence like the SARS-COV2 you mentioned or things I hear from biologist friends mostly along "it is not so simple". Are there good studies that shed light on what are the missing pieces and how can we simulate/model biological processes better?

<comment><USER8> Okay, imagine Mel, of hacker lore [0] had several billion years to write the HumanOS program...

The point is that biology is ridiculously, ludicrously, compressed. Reading a basic biology book introduces you to all of these wonderful and seemingly complete abstractions: DNA blueprints, RNA messengers, information transfer into assembly units constructing little protein machines... at least that's how we wish it would look, and how we abstraction-craving mortals would like it to go.

But Melvolution is parsimonious - it sees a region of DNA and says "well sure that section encodes one gene, but if I bump the read head up by one and start halfway through I can magically read a whole other sequence for this entirely different task. Oh and that RNA you thought was for message transfer, well turns out that the right message can cause the thing to fold up and act sort of like a protein, so let's use that too. And sure this repeated section looks like uninitialized memory "junk" DNA, but it's too much work to take out, so let's arbitrarily read from addresses 12, 42, and 107, and stitch that information into a contiguous unit. Except that every once in a million times the read head can slip and start reading from location 14 instead of 12... and that possibility is __important__ because if you take it out the whole system crashes.

Every possible quirk of chemistry and physics is ruthlessly exploited again and again and again in a million simultaneous ways. Talk about leaky abstractions.

(Not to mention that we still can't reproduce the algorithm reality uses to compute this stuff. It takes a super computer hundreds of hours to simulate a reasonably okay protein fold (which happens in a cell in a fraction of a fraction of a second) - and even then we get it wrong most of the time. )

[0] [http://www.catb.org/~esr/jargon/html/story-of- mel.html](http://www.catb.org/~esr/jargon/html/story-of-mel.html)

<comment><USER9> And the biggest magic that allows for all that complexity to arise is: everything happens in parallel and at the scales that are beyond any intuition of humans. We already know that even extremely simple rules can produce extremely complex-appearing artifacts, like linear congruential generators, fractals, automata, Conway's game of life.

Now, everything is being generated all the time in all the places, in immense amounts of cases, and during billions of years. The results are extremely complex, but those results that we are aware of are only those that survived all the competition and we also see them only as the aggregates.

Humans have problems even just to imagine the exponential growth, because even that is beyond our intuition. In nature, a lot of stuff grows exponentially as long as the resources aren't depleted. That's how the latest pandemics also started to grow, before we limited the possibilities of spreading by the physical separation of human carriers.

</comment></comment></comment></comment><comment><USER10> Thanks a lot for this! Could someone recommend me a good book to start learning cell biology and genetics? I study physics and I'd like to learn about biophysics.

<comment><USER11> The Molecular Biology of the Cell is the standard text. [https://www.amazon.com/Molecular-Biology-Sixth-Bruce- Alberts...](https://www.amazon.com/Molecular-Biology-Sixth-Bruce- Alberts/dp/0815345240)

But you'll probably benefit from taking an Edx course [https://www.edx.org/course/introduction-to-biology-the- secre...](https://www.edx.org/course/introduction-to-biology-the-secret-of- life-3)

<comment><USER12> Do I have to brush up on inorganic and orgranic chemistry in order to get the most out of this book?

<comment><USER11> You should be able to get through with basic high-school chemisty. You need to know there are elements C, H, N, O, P, Ca, K, S, know what an ionic bond and covalent bonds is and be able to look at the structure of a molecule.

<comment><USER12> thanks!

</comment></comment></comment></comment></comment><comment><USER13> Is there are other good resources like this? I am definitely going to read this.

</comment><comment><USER14> Great material, thanks for the hint.

Unfortunately some of the animations require Flash or other plugins which are no longer common.

</comment><comment><USER15> I like this. On a more meta note, does anyone have any generalist advice on picking up the basics of a new field? For instance, I'm looking into hobbyist electronics, but it's hard to know where to start.

<comment><USER16> [https://hackaday.com/](https://hackaday.com/) is a great community for learning hobby electronics.

</comment></comment><comment><USER17> People say DNA is not like computer code. However, it seems that people are really saying it is not like human written computer code. Otherwise, it is still a digital code that is turing complete.</comment>


Scarsdale Adjusts to Life Without Advanced Placement Courses - <AUTHOR> http://www.nytimes.com/2008/12/07/education/07advanced.html?_r=1&em <comment><USER2> Any time you try to compare college applicants by looking at their high school records, which is something college admission offices have to do every admission season, you run into the problem of high school courses not being particularly comparable. That has been true even with the brand name labels "AP" and "IB." The Advanced Placement program caught on not because of school districts like Scarsdale, but because of school districts elsewhere around the United States whose students had trouble making the case that they were ready for tough colleges. Some families, including homeschooling families like mine, really appreciate an opportunity for bright young people to test in what is somewhat like a British A-level system to show what they know.

(Historically, the Advanced Placement program began in the 1950s when prep school students no longer automatically were placed in the same small group of elite colleges. Some prep school students went to pretty good, but not tip- top, colleges and found out they were repeating in college work that they had already done in high school. The AP tests, which began in such subjects as French and chemistry, gave such students a chance to get placed into higher- level college courses that wouldn't repeat what they already learned in high school.)

I'm all for pluralism, so it's fine by me if one school district or another either decides to offer AP courses or decides to NOT offer AP courses. Note that the policy of the College Board is to make AP tests available to homeschoolers and self-studiers of all kinds, so, as the linked article notes, some students in high schools without AP courses still take AP tests.

What would a school district like that say if federal curriculum guidelines became more comprehensive and specified, say, high school level science education standards in much greater detail?

</comment><comment><USER3> My school has done something similar for quite some time - we don't have any AP English or Social Studies courses. Rather, we have a broad variety of electives in those areas. This works extremely well, as students can take courses they are interested in without feeling shepherded into the insanity that is absorbing the entire history of the English language in time for a single exam. We still do have APs in math and science, however.

</comment><comment><USER4> From the article: _Physics students now study string theory — a hot topic in some college courses that is absent from the Advanced Placement exam._

FAIL.

<comment><USER5> Exactly. These students would be far better off mastering ideas like angular momentum and torque. String theory can wait until grad school.

<comment><USER6> Obviously the basics are important, but if string theory keeps them interested - and maybe even helps them decide to continue in physics through college, then including it is a very smart decision.

<comment><USER4> It's a FAIL because they are not learning string theory.

The only way they are actually learning string theory is if the article forgot to mention this:

 _Math students now learn Partial Differential Equations, Fourier Analysis, Complex Variables and Hilbert Spaces -- hot topics that are usually not covered until the 3'rd year of college or beyond._

</comment></comment></comment></comment><comment><USER7> <blockquote>"To us, their courses don't look any different from high-quality A.P. courses," [College Board VP Trevor Packer] said. "Simply changing the letters on the course from A.P. to A.T. looks very cosmetic to us."</blockquote>

I would have to agree; these students are still expected to take the AP exams. If this helps them get away from "teaching to the test," though, more power to them. At my (very good, private) high school, I took the AP English and AP Literature exams without having ever taken courses branded as "AP." In fact, my school didn't even make a distinction between honors and "regular" English; it was just a uniformly excellent program. I got a 4 on both exams. I did take a course called "AP European History," but I cannot think of one instance that I studied for the AP test curriculum the whole year.

But, hey, coming up with a dynamic curriculum that doesn't focus on rote memorization and easy-to-grade multiple-choice tests is hard, especially with class sizes larger than 15-20 like mine were.

</comment><comment><USER8> It was a bit of a personal shock to find this article on HN. I attended Scarsdale High and AP English was one of my favorite classes. That said, it was the strength of a wonderful, memorable teacher -- Julie Leerburger -- that made the class my favorite, not the structure of the AP system.

</comment><comment><USER9> This is good for a number of reasons. One, because everyone agrees that this improves the curriculum and shows that standardized tests can be a handicap even among honors-level students. Scarsdale has courage to be a trend-setter Two, it is a big challenge to CB to get their act together. Some subjects, imo, are better for APs than others. Econ, gov, math, and physics are well- suited, while the english language/lit is pretty much agreed to be the least useful in terms of actual learning. And even the subjects that are best-suited to a test format have their flaws. For instance, CB specifies no definitive textbook for the histories, so you basically need 1 good textbook and a contrasting review book to cover all the material. Even Physics B has it's flaws. Even though the test/lab format works well for the test, NO class ever gets through the last portion on nuclear particles, and there is little understanding of it come test day. Hopefully this will pressure CB to reform.

Also, this could be a good trend considering how exhausting APs are. Colleges look at how many are taken relative to those available, and a chance to be in an "honor's" course without the stress of an AP would be welcome to those feeling pressured to take as many as possible.

</comment><comment><USER10> Thanks for the article; it gives me hope that we can stop obsessing over the damned tests and concentrate on teaching the subject material.</comment>


First chip-to-chip quantum teleportation using silicon photonic chip fabrication - <AUTHOR> https://www.bristol.ac.uk/news/2019/december/quantum-teleportation.html <comment><USER2> Abstract of the actual paper:

[https://www.nature.com/articles/s41567-019-0727-x](https://www.nature.com/articles/s41567-019-0727-x)</comment>


Any HN'ers in Austin TX, or going to SXSW? - <AUTHOR>

I'm a frontend web dev, and heading to SXSW for the interactive section, and some music. Is there any HN community active in Austin with meetups etc?
Can anyone recommend a good place to stay, or a must see sxsw panel?
Just sort of getting a feel for what to expect, any insight is welcome. <comment><USER2> I'm in Austin, but I moved here just recently so I wasn't around for the last SXSW. As far as active HN community, there was a thread about it ages ago, but nothing ever happened (<http://news.ycombinator.com/item?id=3221674>). It stands to reason that we might be able to arrange something with the greater HN community with SXSW.

I'm not going to SXSW as it's not in the job description. If anyone is going to be here [[http://lanfest.intel.com/?page=event&eventid=1874](http://lanfest.intel.com/?page=event&eventid=1874)] on Friday around ~3pm I can probably meet up with you.</comment>