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
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.
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.
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.
* 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.
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.
I'm just going to quote this early part of the document as it summarizes the goal of pessimal algorithms - to design a program to always get closer, but as slowly as possible.
"Of course, we can get very slow algorithms by adding spurious loops before the first test of X against
the Ai
. However, such easy solutions are unacceptable because any fool can see that the algorithm is just
wasting time. Therefore, we must look for an algorithm that does indeed progress steadily towards its
stated goal even though it may have very little enthusiasm for (or even a manifest aversion to) actually
getting there."
One of the best decisions I ever made was to admit failure early when I saw it coming. It wasn't ambiguous or one of those "if I try hard enough, I can turn this ship around" situations. It was clear that my idea, project, marketing efforts -- all of it -- was essentially going down the tubes. The cash in my savings account burnt off like fog on the Golden Gate. These are standard pressures, but there were some systemic things that keyed me off to how clearly it had failed.
For one, my heart wasn't in it. It was like I had spent months crafting an idea that I thought an audience of customers would receive happily - only to realize I wouldn't use it or care about it myself. It also had become a business proposition I couldn't succeed at myself. I needed more help than ever.
So I packed up my stuff and killed it. It was painful, but I am glad I had the ability to see the truth before getting so bad as to be like the scene painted in this post. That said, it's not always obvious like it was in my case; I have tremendous respect for folks that go through this and fight to the bitter end.
Very cool. I ran this, adding a print statement into the Filter function so I could inspect `i` as the channels received inputs. I expected the prints to come relatively in random order but on repeated tries they didn't - and then realized I know nothing about programming with coroutines and explicit communication between threads. Thanks for the thought exercise!
Unfortunately it's not hard to manipulate this one. AR generates a couple queries when you do a single invocation - the first is a meta data query to get info about the table you're talking to. The second (or third, etc) are the actual hard queries.
It's the first query, the metadata one, that applies the passed arguments in a raw form directly to the query. The exploit takes place inside of a 'show' operation. It's totally unprotected and lets you run pretty much any select you're interested in.
It also goes beyond prepared statements - the metadata query in question is totally separate from the one specified by any parameterized query you'd pass using something like ('id = ?', params[:id]). So essentially, as a developer, you can't do anything better. This is kind of on the framework side alone :/