mcless

I thought the parent comment was referring to real offline journals made of treeware.

Why not use something like http://github.com/susam/texme as a starting point? Really easy to turn any Markdown document into a rendered HTML with a single line of code in the header.

This rendered HTML could be converted to PDF and printed or the self-rendered HTML itself could be printed directly.

That makes sense. Thanks for explaining.

This project too is a solution built on WSGI like Bottle and others. I agree plain WSGI is too restrictive and tedious to work with. So I don't understand how the parent comment's concerns about WSGI applies to this project but not to other WSGI-based frameworks.

Aren't Flask, Django and Bottle also built on top of WSGI?

> Less output == less revenues == ultimately less pay

Where is the math that working for 4 hours produces less output than working for 8 hours?

Also, like I said before I don't believe that less output == less revenue. Like I said, I have seen no correlation at all between working more number of hours, or producing more output and revenue. What I have seen though is a strong correlation between working on the right problems and revenue.

You are free to believe what you want. Similarly, I am free to believe what I want based on my experience. As a result, I work for companies that don't have a culture where they believe that output is always directly proportional to number of hours spent. A company that believes working for 8 hours leads to more productivity and I may not be a good fit for each other.

@clarkevans But submitting search input via the GET method (e.g. https://www.google.com/search?q=how+to+stop+drinking ) are a common practice in leading search engines.

During the time I worked for Amazon, the entire Amazon infrastructure was written as services. It indeed felt like a bucket of cold water in my first month at Amazon, especially after having worked in software products company for 10 years prior to that.

But gradually, I got used to the services based architecture, where something as simple as presenting a login page would lead to dozens of REST API calls back and forth between various backend services.

I am not saying that one approach is better than another. I would have to dedicate a separate comment to discuss that. All I am saying is that developing an entire software system composed purely of generic services with HTTP based REST APIs indeed exist and are very successful in very successful companies.

You seem to be making an assumption that just because you have not seen companies where the management encourages cutting down on daily working hours, then such companies must not exist. From my experience, I would claim that your assumption is false.

During my career, I have worked for a few small as well as big companies where the management indeed encouraged limiting the working hours to about 4 to 6 per day. All of them had 40 hour week on the contract or legal agreement but the company culture went beyond the written contract to support something like a 25 hour week.

In my career, I did not see any kind of correlation between financial success of the company, productivity and the number of working hours. Financial success had a strong correlation with good decisions made by higher management. Productivity had a strong correlation with high skill-level of engineers and managers hired.

Another way to describe what I mean is: When I worked for one of these companies that encouraged four-hour working day, there were competitors who worked the regular eight-hour working days and were beating us in the competition, and there were also competitors who worked the regular eight-hour working days and were losing to us in the competition.