1. https://www.siidorow.com/master_Siidorow_Mikael_2026.pdf 2. https://aaltodoc.aalto.fi/items/e71b388a-a015-4f01-b7f9-530e...
85 karma · joined July 5, 2012
1. https://www.siidorow.com/master_Siidorow_Mikael_2026.pdf 2. https://aaltodoc.aalto.fi/items/e71b388a-a015-4f01-b7f9-530e...
Overall that's a good point, though, and for this reason I do this with only select few of my students. :)
That said, I see no problem in subsetting or customizing the font especially in personal context. The website even provides tooling for this purpose so it's definitely within the license since you are literally creating your own custom version on the fly.
I hope this clarifies why it seems to be a standard clause for fonts.
For the next paper, I plan to have a look at a couple of disappearing frameworks in detail. Let me know if you have special requests on what to research. :)
In short, it's definitely possible to earn a living out of technical writing. Getting started is the hardest part. If you don't have a reputation, you will need to build one. Growing audience will take time, but it will pay dividends.
To keep this comment short, I'll just link to a series of articles (and presentation slides) I've written about my experiences. Hopefully these help! Here we go:
* http://agile.fi/survivejs-writing-a-book-in-a-lean-way/
* http://survivejs.com/blog/succeed-at-technical-books/
* http://survivejs.com/blog/survivejs-interview/
* https://survivejs.github.io/how-to-write-a-book-and-survivej... (Chrome works the best)
Best of luck!
I just published a new version of SurviveJS. Feel free to ask anything about the effort. :)
I feel adding vocabulary like this to a system can help with understandability. That's the point I made with a "feature". It's something that could fit between views and components.
Atomic design (http://patternlab.io/) is close to this idea.
That might give you alternative ways to think about contracts. In short, because we aren't contracting right, all parties end up disappointed. I would say this is one of the main reasons why software projects fail. We sell too big projects (more likely to fail), buyers don't know how to buy (or what they need), we specify too much beforehand (and then stick with that...). There are so many traps.
Speaking of outsourcing it all depends on what kind of a relationship you want to build. I think some of this depends on legislation (ie. hire vs. buy). Construct incentives so that they are win-win.
The data is based on Pingdom, yes. Recently we made sure each CDN is monitored from the same group of servers.
It's probably not ideal. It definitely would be great if we could provide some alternative metrics. Ideas are welcome. :)
You might want to check out Esprima (http://esprima.org/). You will find a couple of alternatives there. See http://code.google.com/p/traceur-compiler/ as well.