Exactly. It's not that I don't see value in online alternatives, but in this case, if the main point is to access it offline, I don't see how different it is from a physical journal.
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.
There are a whole bunch of similar tools written in all sorts of languages, and OP just chose what he's most familiar with. It just happened to be different from your favorite toolchain.
It also looks like OP's book was split into several Markdown files, one for each chapter. So he would have needed some sort of build script anyway if he wanted to use texme on the combined document. He would also have needed more than a single line of code in the header, since he wanted some custom styling for blockquotes and code snippets.
I think that's what your parent is saying. There are good solutions built on WSGI, and WSGI itself is restrictive. Not to take anything away from this project.
Exactly. If you build an async project, but do the same things than WSGI frameworks we gain nothing. We already have perfectly capable and productive frameworks. We use them everyday, we make money with it. They work.
Async allows to maintain low latency permanent connections between each clients, being it a web page, a task queue, a server worker, etc. We finally can have it all connected. We can broadcast setting changes, propagate cache invalidation, push action notifications, update task completions to subscribers, allow everybody to react to stuff on the file system or the db instead of polling, all in soft real time.
The potential is amazing.
We all can do HTTP req / resp. The question now is: how good the tooling around this cycle is.
Sorry, it was a vague attempt to foster discussion about the options of moving out of WSGI without throwing it out completely (I was really ill yesterday and couldn't quite formulate any logic thoughts around it myself).
Have you looked at the options there / if there would be an easy way to bolt on a more async driven framework? Obviously, it doesn't solve the missing framework issue, but maybe there's some clever tricks you can do because uwsgi is allowing you to bend the rules.
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.
There are already good solutions for WSGI. There are less for non-WSGI async options. The parents point is that if you now create something new, yet another WSGI solution doesn't add much to the general ecosystem, where a new async thing very well might.
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.
Absolutely. At Amazon's scale, the justification is there. Things are different for invididual developers and small teams where the mesh of services will be maintained by the same people anyway.
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.
I'm not assuming that, I'm observing that the review doesn't reference any of them, and wondering why (just like when we'd read an article about how some super-successful startup founder owes his success to broccoli, we'd wonder what happened to all the broccoli-eaters who didn't end up as particularly successful).
When you're recommending specific radical reform, it helps your argument to analyse specific implementation of said reform, rather than merely extrapolating from a cool research article and sprinkling a few historical anecdotes.
I can believe that people normally can't get as much done in the second 4 hours of their 8 hour day as they do in the first 4 hours.
I can't believe that people can get as much done in 4 hours as they can in 8 hours.
Less output == less revenues == ultimately less pay. You can't change math, companies aren't going to get paid the same amount for making less stuff or providing less services.
Maybe the difference is only 30-40% less instead of 50%, but I think most people are willing to put in the extra 4 hours for the additional benefits.
> 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.
