bebraw

I have alternate links for you:

1. https://www.siidorow.com/master_Siidorow_Mikael_2026.pdf 2. https://aaltodoc.aalto.fi/items/e71b388a-a015-4f01-b7f9-530e...

Let me see if we can get this on ResearchGate or some other platform. Maybe Aalto servers didn't like us.

I brought this up because of the exceptional quality of the work. While limited to web, I believe the findings are interesting enough to be shared with broader public.

Overall that's a good point, though, and for this reason I do this with only select few of my students. :)

Can you open an issue at https://github.com/MonoLisaFont/feedback/issues ? Maybe that's something we missed while restructuring ligatures for customizability.

The free trial version has a couple of fixed weights to try. It's missing all the advanced features (variable weight etc.) but it's enough to get an impression and to use it on a daily basis to see if you like it.

One of the main challenges related to web development is maintaining state across the client and the server and most web applications have to solve this somehow. Because of this reason, so-called sync engines have become available as they can own a large part of data synchronization.

In his MSc thesis, my student Mikael Siidorow looked into the space to find out the limits of generalized sync. He did his study through multiple methods including literature review, interviews, and a case study. In the end he came up with a taxonomy showing where generalized sync breaks and what you have to keep in mind when implementing these solutions.

This is not to say sync engines are useless, but that there are clear tradeoffs to consider when introducing them to your codebase especially if you have to deal with an offline requirement.

Thanks for highlighting my paper. I agree htmx is an interesting one to cover in future work and I have listed it as a reference on my state manager (https://sidewind.js.org/) as a related approach. It would be highly interesting to rewrite Sidewind as a compiler so I can do more granular bundle per page (or for the entire site if I capture from all the pages as that's enough for many use cases).

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. :)

I just self-published my first book (http://survivejs.com/). Writing books is way harder than people think. Writing isn't enough as you need to tackle other aspects, such as marketing and sales, as well. If you are not native, you have the extra challenge of learning to write.

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!

Hi,

I just published a new version of SurviveJS. Feel free to ask anything about the effort. :)

Yeah, it's bit of a stab. I'm really curious to see how GitHub responds (if they respond). A lot of good could come out of this even if it takes some competition to force some of that.

I see view (or screen) as something that maps to a route. It's true it's definitely a component.

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.

I suppose someone could write something like this on top of the API, https://github.com/jsdelivr/api .

Blog post related to the first slides: http://thehoustonway.com/2013/02/25/fixed-scope-fixed-price-... . Maybe that'll help.

I agree selling hours doesn't feel right. Rather than bore you with yadda yadda, please go through the following slides: http://www.slideshare.net/AnttiKirjavainen/a-minute-of-our-t... , http://www.slideshare.net/juhailola/agile-contracting-killin... .

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.

Nice point. We've been planning a map based visualization. That would definitely help in this regard.

Hi,

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. :)

Good points. Any specific ideas? The Twitter feed could go, that's definitely true.

Great work. Cheers from the http://jster.net folks. :)

Cool. Thanks! :)