sentiental

Thanks for looking! Yeah, I managed to typo the HN example - yes, my existing templates contain type="text/template", and I think that's how I filed the bug. It's possible for me to inject those templates with a variable instead of including them directly in the template, although that's a bit more invasive of a change than what I was doing before.

One thing that might snag web applications built with Go 1.8 is the change to the html/template library. If you ever need to include script templates in your HTML for usage by a Javascript template framework (in my case it was EJS), then you will need to be aware that html entities will be escaped in a way they were not in 1.7

Given the following literal:

<script type="text/javascript"> <div><%= something %></div> </script>

Go 1.8 will escape the EJS delimiter, breaking the template. I.e.:

<script type="text/javascript"> <div>&lt;%= something %></div> </script>

I selected EJS specifically because I wanted a templating library that didn't conflict with html/template's handlebars syntax. If you're in the same boat you'll want to find a template engine with non-html entity delimiters.

I am starting to think they'll be recommending we use `go generate` to do handwritten templates before too long. It saves them the hassle of building generics into the type system and they clearly want it to be part of the build cycle.

http://blog.golang.org/generate

I have been concerned that Docker's scope was expanding too far for a while now, so I'm glad to see an alternative that might work appear on the horizon. That said, I am somewhat concerned that CoreOS has a suspiciously similar business model to where Docker would probably like to be.

It's in a business's best interest, and exceedingly common practice, to "land and expand" with something clear and compelling, and following that add features to compete with alternative solutions. I don't think there's anything inherently altruistic about CoreOS that would keep Rocket lean in the long-run, especially as they begin migrating their various tools away from Docker containers.

One of the authors here. We didnt want to change the AST in a way that would be backwards incompatible with vanilla PHP. There is some luxury in being able to turn off this extension when needed. We also have a large enough existing codebase that switching to SPL types everywhere was a non-starter. Our goal here was partly to be able to use PHP's native types and still get some good coverage.

Phpdoc may not seem ideal, and it's not, but it has afforded some significant flexibility

More that, if you were to never work again (and factoring in some reasonable age starting point) you would be able to live a lifestyle that matches someone who has a lower paying job.

$2M/30years => $66k/y.

This seems representative of the PHP community in general. The only thing you need to qualify PHP as being "beautiful" is to apply a few tips on how to iterate over your array.

There are many other ways to make PHP beautiful. In fact, you can make object models that are almost as flexible, DRY and elegant as they would be in any other language.

I fear what will happen when the market for pure misinformation is fully realized. When it can be delivered as seamlessly as the real thing, the opportunity for profit is massive. The Atlantic is an example of media engineering for profit that fails to trick us -- but it is much closer than sponsored content has been in the past and certainly more effective at getting me to consume it than a regular ad.

Call me a conspiracy theorist but one thing the future holds for us is more of this. Except it will take place in scientific literature, respected publications, maybe in our own homes and (purposefully or not) by the people we know and trust. We'll need a factcheck.org for regular news.

"Sponsor post" is probably as good as we will ever get from The Atlantic.

There are a number of mock object libraries out there (mockery, shmock, phpunit's mock syntax, etc). This just looks like another builder syntax for making mocks / stubs with some fanciness around class extension - what's the benefit?

Also, how often is it useful to define a class at test time that is initialized by production code (from the section I Still Have Serious Dependency Issues!). This seems like an unlikely use case.

What encompasses typography theory? Like semiotics / linguistics or something more specific to web font use?

* To learn and get a deep understanding of Go (golang) * To find a project thay excites me and that I believe I will be able to sell. * Meta-goal: to set adequate goals for myself so that I can keep learning, working and building without burning out.

I appreciate the technical rigor required to make this kind of service stable and safe, but I am worried about the usefulness of the product / who would use it. Building APIs into my own abstractions in a real web application basically means I'll never use this myself. A more casual developer may use this to build simple mashups, or maybe hack out something for a hackathon, but beyond that why would I go through the trouble of figuring out how to integrate webshell with my own codebase? NinetyNine already mentioned this, but now I'm adding a new single point of failure and another web request, so I'm not quite sure how big the benefit is exactly.

Maybe it'll turn out that there's a huge need for some intermediate between IFTTT and vanilla API use, but I'm having a hard time seeing when.

Nifty, I hate going to the Github UI to do some of this stuff. Is Hub backwards compatible with existing Git commands?

Without being quite as harsh, I generally agree. I have generally found new or inexperienced developers become scarred by projects that fall behind more than projects that grow out of control, and bias more towards getting something done, fast. Totally agree that the best advice for OP is to not underestimate his own ability to perform well in a better language. I think it is folly to assume you need a less structured language to get up and running faster.

This very much reminds me of the Worse Is Better line of thinking.