One of the features I like is default parameters. I'd like to add a usage that isn't mentioned in the article. It's really handy to pass optional parameters since default parameters can be nested.
class Hoge {
foo({active=true, collapsed=false, silent=false}={}) {
}
}
let hoge = new Hoge();
hoge.foo({collapsed: true});
In the blog article above, they mentioned a problem they faced.
> The docs were built around Hugo, which is not natively supported by GitHub, and took minutes to build, and even longer for us to deploy.
I've been using Middleman for static site for a couple of years. I'm thinking about moving to Hugo because I read HN comments Hugo is much faster than other alternatives. But reading the official Docker blog, I'm thinking twice.
Could anyone tell me the reason why Docker blog took too much time to build with Hugo that is supposed to build really fast?
> the reason why Docker blog took too much time to build
Not the blog, but documentation. And it takes so much time because it's just so huge. Just by itself it would be pretty big, but consider that they maintain a clone for each release version. You end up with lots of documents very fast.
What I'm not sure about is why it would have to be completely rebuilt every time since the build results would have to be committed. Maybe they had two repositories? Or Hugo can't do "incremental" builds well?
Disclaimer. I am the author of Hugo and former exec at Docker. I don't speak for Docker and I've been gone for over a year so the following is at best a guess.
From my reading of their blog post I see that their primary motivation for the change was first to consolidate all of their documentation into a single repo, instead of spread across all of their various projects. As they have grown as an organization and now have a large number of projects this approach has a lot of strengths and makes a lot of sense. Any SSG could work in this new formation, but the change gave them an opportunity to make a change. Additionally Github provides a lot of Jekyll features out of the box that help with managing these documentation sites.
I believe it is not a question of performance between Hugo and Jekyll, but a question of Docker's specific workflow. As Github already runs Jekyll server side all the contributors need to do is upload the source file and then Github does the rest. In contrast, Hugo based docs would have to be built locally and then uploaded as completed html. There are easy ways to set up services through github hooks that do the exact same thing as Jekyll already does but that requires additional setting up.
Since Github is doing all the work it is easier on the contributors since all they need to do is `git push`. This also enables people to edit right in the github edit screen and not bother with setting up anything client side. The total time to process the site is likely much longer on Jekyll but the time that their contributors spend is much less as they aren't building the site locally.
I'm using feedly.com for reading tech blogs. For long articles, I use getpocket.com to read it later instead of Feedly's 'Read it later' feature.
Both service give me the hints of popularity of the article. Pocket adds 'Best Of' label for popular articles. Feedly adds a number of 'Read it later'.
I'm currently using Feedly for subscribing podcasts. But it's not handy to use. If RadioPublic give me the same feature that feedly and pocket provide for the sake of podcast listening, I'll definitely use the service.
I'd quote an interesting point of view on MBA from Joi Ito's TED talk.
Before the Internet, if you remember, when we tried to create services, what you would do is you'd create the hardware layer and the network layer and the software and it would cost millions of dollars to do anything that was substantial. So when it costs millions of dollars to do something substantial, what you would do is you'd get an MBA who would write a plan and get the money from V.C.s or big companies, and then you'd hire the designers and the engineers, and they'd build the thing. This is the Before Internet, B.I., innovation model.
Sorry for the late response. But from looking at the Madrill site, it looks like the API is a RESTful API so you should be able to use it with Python. And also should be possible to build a Python wrapper for it.
https://babeljs.io/docs/learn-es2015/
One of the features I like is default parameters. I'd like to add a usage that isn't mentioned in the article. It's really handy to pass optional parameters since default parameters can be nested.