imsky

I've been working on a similar project - open source interface design tool with SVG as document format. Glad to see others think it's a good idea, too.

There's an impressive amount of functionality just in the alpha release. Looking forward to seeing how it evolves!

Will be interesting to see if this becomes the Google Reader replacement missing all these years. Substack is uniquely positioned to offer this kind of product.

Great stuff from Stitch Fix as always. Concise and readable, good visuals, connects real problems to theory. Wish more companies did this.

I got started on Freenode IRC channels - someone had a question and it turned into a couple of years of freelance work. I went through marketplaces, but even 10 years ago, the race to the bottom made them an unprofitable channel.

Freelancing lets you build up a portfolio of work, build relationships with people who can give you work or referrals, solve problems in different domains with different tech stacks, and test yourself as a sole proprietor. It helped me get a lot of experience in a short time.

Times change and these days I would only recommend freelancing for people starting their careers or for people who need some income quick. There are a few issues: you usually won't be trusted to work on mission critical parts of the business, clients care less about quality than you do, sometimes you have to take work that's incompatible with your career goals, and price-sensitive clients can be difficult to deal with when it comes to payment. Looking back, I'd likely do it again, though I'd charge more and be more selective about projects.

https://www.webliero.com shows it's possible

you're not alone

i could write the same post word-for-word

start your own company

archive.org has a copy: https://web.archive.org/web/20170707011101/http://www-cc.cs....

Right, the hung nodes issue is probably least related to kops (though it'd be great if in the future, kops could leverage something like node-problem-detector to mitigate similar issues). Of the other issues, the incorrectly applied cluster config (kops decided to update certs for all nodes and messed them up in the process, then proceeded to mess up the Route53 records for the cluster) is the most serious one, and also not likely easy to reproduce. Apart from that, kops has been an excellent tool and we've been very pleased with it.

We've been running a small Kubernetes cluster of < 30 nodes that handles a variety of workloads using kops for almost a year now. kops is a significant improvement over other provisioning tools like kube-up.sh and kube-aws and has simplified infrastructure management a great deal. We can provision a brand new cluster and a couple dozen services across multiple namespaces in less than an hour - kops helps a lot with making that process smooth and reliable.

We have run into some issues with kops. Customizing the Kubernetes executables, e.g. using a particular Docker version or storage driver, has been buggy pre-1.5. Upgrading clusters to later Kubernetes versions has left some of the kube-system services, like kube-dns, in a weird state. Occasionally we encounter issues with pods failing to schedule/volumes failing to mount - these are fixed by either restarting the Kubernetes (systemd) services on the problem nodes or by reprovisioning nodes entirely. On one occasion, a bad kops cluster update left our networking in an unrecoverable state (and our cluster inaccessible).

I don't think there are any missing pieces, the initial configuration is what usually takes the most time to set up. You'll have to become familiar with the kops source as not everything is documented. As far as running 30 clusters with a 2-person team, it's definitely feasible, just complicated when you're constantly switching between clusters.

git clean -dxf is part of git fresh -F

what git fresh also does is rebase local master against remote master, prune stale remote-tracking branches, optionally rebase current branch against remote master, optionally delete merged remote branches, optionally hard reset local master to remote master and clean the workspace, and stash/apply any uncommitted changes prior to usage.

The closest Standard Markdown provides is the re2c "source" that gets converted: https://github.com/jgm/stmd/blob/master/src/scanners.re

I agree that a universal PEG would be great, perhaps this is the project to base that grammar on.

Good catch. Updated at https://github.com/imsky/LocalEuler

Great project, now with a Github version: https://github.com/imsky/LocalEuler

Yeah, I noticed that, too. "Just be an expert at identifying successful startups early and get a job there."

Is insurance provided for book loans? I know some people keep public library books forever and just renew them, how is this issue addressed?

In the old days people had huge lists of links to friendly sites. That was social networking without the middleman.

Right, that's the fallacy being made constantly here - as if Weebly and Google Maps are taking jobs from developers, when really there would have been no need for a site or a mapping component in their absence.

Good point, but we've always been automating software, and so far the market for it has been booming. The idea of "peak software" seems to involve assumptions that just don't work in the case of software development. It's worth thinking about software as more than just web development problems - think energy, education, entertainment, sports, media, recreation, art, manufacturing (big and small), virtual reality, and so on. The solution space is enormous, practically infinite.

Thanks for bringing that up, excellent article.

Good point, but it touches on a refrain I've seen in the comments: that it might be better to keep the world in an inefficient state. Standards rise up after the complexity of interoperability becomes too much to handle.

As to your point about information, the volume of data these days requires increasingly sophisticated analysis. There seems to be a shift in sentiment around Big Data, that algorithms are still too unsophisticated to provide useful output, and that's a good sign that not only is there a lot of work to be done in this area, but a large volume of information doesn't automatically guarantee quality insight.

Exactly right, it seems many people assume that automation or offshoring will be a smooth and seamless process with no trade-offs. That's not the case at all, offshoring and automation present their own kind of problems.

@timr:

Well, first off, you're just shifting the goalposts and redefining what it means to "program" to suit your needs: it's inconvenient for your argument that there's now software that does what programmers used to do, so you just call those things something else.

Definitely not. I think "website automation" is among the simplest kinds of software automation and historically it has not required a significant amount of programming.

But it doesn't matter, because you can't run from the core of the argument: it isn't limited to static HTML & CSS. Want web forms, but don't know how to write software or use databases? There's Wufoo, and dozens of others. Want to send email? Mailgun. Mailchimp. Want to accept payments? Paypal, Stripe. Want to show an interactive map with stuff on it? Google maps has you covered. Want to implement search on your website, but don't know anything about search? Swiftype will do that. So will Google site search. Need a sophisticated customer analytics system. OK. That'll be one line of javascript, please.

That's a stretch. Wufoo, PayPal, Stripe, Mailgun, Google Maps, and MailChimp are not going to cover 100% of use cases, nor do they all come free. You're also ignoring that many of these services are alternatives, not integrations (MailChimp, PayPal, Stripe, Mailgun, Google Maps), of older services (AWeber, Authorize, MapQuest) that filled the same function, and a few of them are filling a need that simply didn't exist before prior automation tools (MailChimp for email lists, Stripe for payment processing). It's not a zero-sum game, nor do the same players stay on top throughout time.

And what's more: it's only a matter of time before someone rolls all of these tools together into a pointy clicky interface that eliminates the token integration work (assuming they haven't already). There's no part of your argument that is safe from the trends that have been driving our industry.

I actually mentioned that in the post: "For every API that wraps around a business process, there's an application yet to be written (and an API around that application in due time)." You seem to think there's some end point, where most software will just be done and most activity automated. I doubt that will ever be the case.

True, but like I said before: almost nobody needs that. There's always going to be the need for complex software...it's just not clear how many people will be asking for it.

You seem to imply that in the future, most non-complex (i.e. average) software will just either exist or be generated on demand. That seems far-fetched - there are programs orders of magnitudes simpler than "software generators" that routinely need to be adjusted and tuned to produce correct output (as will all the automated APIs in the future).

Knowledge workers are definitely not immune to automation, I've acknowledged that in the post. They do set the bar quite high for software and intelligent agents, however.

Regarding your last point, I think a knowledge worker smart enough to automate themselves out of a job will be smart enough to capitalize on that discovery. Moreover, there will always be tasks people will prefer done manually, knowledge-based or otherwise.

The first part is technically true - the automation team can exceed the original team, but this may be a special case of "engineers untangling a mess of functionality accumulated over the years." The second part has an exception of its own - there doesn't necessarily have to be a complexity threshold, developers "over-automate" simple processes all the time (e.g. Microsoft).

@lightcatcher:

Previously, most people would say that it requires programmers to make a website.

It hasn't required a programmer to build a website in many years now - HTML and CSS were declarative to begin with. It's only with the advent of CMS's - which are definitely NOT all automated (i.e. Joomla or WordPress) - that programmers entered the picture.

Re Re MBA guys - I don't know how many MBAs are working on something more complex than another social network, because many successful businesses recently have been quite easy to build a MVP for with not a lot of programming skills.

Good point, but are they doing it? Facebook, Twitter, Instagram, and Airbnb all had technical founders. The true complexity of these startups lies in their server software - how to optimize at scale and so on. An MBA aware of this complexity deserves all the success he or she can get.

That's a gross oversimplification of what I wrote. If you take only Baugues's conclusion ("don't be reckless, save and network, things may not always be so great") and ignore his premises, you're reducing the article to a platitude. My intent was to show how fears of automation are nothing new and should not stop developers from pursuing their careers.

That's a good point - there can be serious career opportunities in managing, supporting, and modifying ostensibly "automated" solutions. The core may be automated, but the ecosystem doesn't have to be.

Great point. The nature of the work changes as old complexity is automated away, and new growth possibilities arise as a result.

@nrivadeneira: Yes, the point Ford made works, but it works because of the _nature of the jobs_, not because of any inherent property of theirs that influences their compensation (implied by Ford to be the knowledge/labor distinction). Clearly you and I can think of high-income location-bound jobs (bodyguard) and of low-income information-processing jobs (library clerk).

A good point, but an obvious one to economically-literate readers. The counterpoint to it is that it requires fewer developers to automate a process than it requires to write it. In the short run, unemployment may increase, but in the long run, it'll stabilize.