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 think your comment above isn't quite right. The problem you're seeing is that previously this was escaped as js (incorrect), and now it is escaped as text (correct). If you set your type as above to "text/javascript", it works in go 1.8:
the one that fails is if you set the type to text/template or similar, which makes sense I guess as it is not js but might be annoying if your library uses <> as delimiters. Should work with text/template though if you mark those snippets as template.HTML type before including in an html/template.
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.
If it is true, please don't use the text template as a quick fix. A lot if security thinking went into the html template and without it you will have xss all over your code.
Edit: sure enough, it validates type against know values and I assume jsx is not over of them.
then it won't be escaped presumably as js, but it will become js when it is run through the other templating system. sentiental have you tried that approach?
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.
> Just keep in mind that it is for package authors, not clients...
Generics by author-template sounds exactly like what the Go authors would want: source code is still shared (rather than binaries), no Make/Include/Macros for the build, and no hassle for the _user_ of a package.
> Also, if the containing package is intended for import by go get, once the file is generated (and tested!) it must be checked into the source code repository to be available to clients.
Moving external processes into the source code is characteristic of how they've developed Go.
A GCO/SWIG style generator built-in to `go` would be a great next step. It wouldn't have to be perfect, just deal with includes and defines separate from Go build. Even if the output needed to be hand edited it would be a great starting point.
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.
I had the same initial reaction, but I think there's good reason to trust the CoreOS folks to remain faithful to the project's goals. Containerization (although foundational) is one part of CoreOS's platform. It's easy to see where the boundaries fall, e.g. I expect systemd and fleetd to keep their respective functionality and not overlap with Rocket.
It become pretty clear once dotCloud became Docker Inc. that they intended to capitalize on the "Docker" brand to sell an integrated orchestration platform. CoreOS already has enterprise customers for their operating system and related components. They seem like the perfect team to take this challenge on.
The difference here would be, IMO, that they have clearly made openness one of Rocket's goals: the formats should be well-specified and maintained separately so that other implementations can run them.
I hope you can understand that it's frustrating when, after hard work pitching an API to dozens of ecosystem players, spending weeks trying to wrangle a working implementation which makes as many of them as happy as possible, without compromising integrity of design - after all that, in the end, all it takes is one unhappy camper to write a blog post and that immediately tramples everything else.
It's even more discouraging in this particular case, because after this blog post, Alexis and I have discussed this topic extensively, and as a result he has since joined the effort. In fact I will be hacking with him in person on integrating Weave as a native networking plugin in 2 days in Amsterdam.
So, sorry for the insta-snark. But it can be frustrating to see so much good will and hard work be crushed in a second.
Hey, regardless of the technical sides of anything, I'm sure this is not a fun day for you. I think you're handling the situation terribly, but still, not a fun day. Anyway, docker is awesome, and thanks for building it. I know it's made my devops life a lot more enjoyable of late.
Concerning Weave that's quite a good news, the weave point of view for docker networking is good and can be easily setup in many (not all of them of course) infrastructure.
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
Thank you for your response, that's good reasoning and I definitely see it works well for your use case. It just seems as if multiple companies are coming up with solutions to work around deficiencies in PHP which is causing fragmentation in the language. That's not going to stop me from using this extension in a new project I'm starting though. Are there any areas of this extension you'd like to see improved since I find the best way for me to understand an extension internally is to work on it.
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.
If you haven't read Stephenson's "Anathem", one of the characters makes a reference to Bogons, false pieces of information inundating the Internet.
There are low-quality bogons (the example given is a file full of gibberish) and high-quality bogons, masquerading as legitimate data but differing in only a few places, and hard to detect as such.
This is definitely a fairly high quality bogon, at first glance.
I found this advertorial (common in newstand rags) to be incredibly informative. First, Scientology is expanding around the world. Second, I thought Scientology was banned in Germany but they opened a Church in Hamburg. Perhaps I'm just ignorant, but that was a surprise to me given their problems in the EU. They have clearly figured out how to "manage" there. Third, politicians from both parties, federal and local officials attended these events. They are becoming more and more "mainstream"
Finally, this expansion and the choice of buildings means they have a lot of money. They also have a very good taste when it comes to architecture (IMO) - they didn't build giant $100M sun temples or edifices, they've found what appear to be amazing examples of local architecture and have adapted it to their purposes.
Would that most "real" editorials were so informative.
For a (hopefully) fictional example of how this could already be happening without our knowledge, check out the film "The Joneses". Pretty entertaining film too.
I don't know. Although we are talking tail end of the 90s, there's passing reference in No Logo/The Shock Doctrine (forget which, but think the former) by Naomi Klein to lifestyle marketers that would follow a couple of people in their target demo around without their knowledge.
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.
1) To avoid the complexity of existing frameworks.
2) To be able to quickly and easily test code with various kinds of dependencies.
It is predominately designed to test a single class in an extremely isolated context, not in the context of a full blown testing framework.
It is designed to be a stupid as possible with the intention of allowing the developer (myself) to define very strict test condition and very fine grain control.
* 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.
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><%= 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.