It reads to me like a self important rant. I don't know what the author tried to do to resolve these issues, but the tone of the article doesn't make me optimistic.
I really like the idea of merge conflicts being resolved in the open in a pull request, instead of the pull requester working in seclusion. For those of us with projects on GitHub, is there any way to replicate this behavior there?
There is no magic to avoid this problem. If you are trying to get changes into a repository that is constantly changing with no good isolation of concerns, then expect pain.
Otherwise, merges really are better from most perspectives. I can trust people doing pull requests to have tested their code. Looking at the log, I can get an idea of whether or not their code was tested with someone elses. Something I can not do with a pure "rebase and push" mentality.
A commit message should be formatted like an email to your past self, or your future collaborators. It should have a very descriptive and concise title (the first line of the message) written in the present tense and after a line break you should (when necessary) write an email style explanation of the reasoning behind the commit.
If you fixed something, is there context that should be useful for someone discovering this commit in a vacuum. Are there any related commits? If you added something, why? There is so much useful information that can be encoded in a commit message and discovered when someone does a `git blame` for example.
I'll agree that being in interactive editor is a more conducive setting for this kind of message, but you can provide both a title and longer description via command line by specifying the -m option twice, e.g.
git commit -m "fixed the widget factory" -m "It seems like we keep getting wooden shoes stuck in the machine, so I added a ShoeClearingDaemon process to check periodically and restart the machine if necessary."
I'm pretty pleased with lollipop. Some of your complaints may be down to personal choice, but not all. For example, the triangle animation changes from pointing left when the action would be 'back', to down when the action is 'down', as in hiding the keyboard.
Some other thoughts:
- Getting to settings is no different from before when I had to swipe down and then tap a button to see the settings button. Now it's two swipes instead.
- Try schedule view in calendar for the overview you're looking for.
- The double tap on notifications to open them I like because it means I won't accidentally open one.
Things I've said 'oh, cool!' to:
- Guest accounts
- Brightness slider in the swipe down
- Priority/None interruption settings for the ringer. I used to use Shush! but this works nicely and with more configuration options, albeit less granular timing.
- Lock rotation in the swipe down settings
- Flashlight in the swipe down settings
If .rtf/.doc is in such high demand, can't we output to those formats using LaTeX? I think of it as just another output alongside dvi/pdf/etc, but I know very little of the internals that would generate those additional formats.
I mean, I view .DOC was worse than Latex in terms of ability to correctly render it in the future, ability to generate complex documents correctly from originals, ability to programmatically interact with it, and generally anything to do with the future.
I'm tempted to go down some XML path, because that separates concerns between the semantic structuring of the document/corpus and the rendering of it, but is that really better than just using a declarative subset of LaTeX and worrying about correctly implementing the styling scripts to render them as desired?
I have my doubts it would really be an improvement.
For context, I have a project at work coming up for which I have a bit of time to establish a toolchain and our format for things like documentation, specifications, etc. I'm open to the suggestion I should spend some of that time working on a system to make sure we don't hit a rendering issue on a technical manual in a few years when technologies change. (I'd also like to look in to literate programming tools, so semantic demarcation for automatic selection of certain kinds of elements in the document is high on my list of things to look in to, as well as relationships between and metadata in those blocks.)
I'm just not convinced that trying to replace Latex with XML or anything of that nature is actually going to make my life better in those regards, rather than being a waste of time.
(If you haven't noticed, XML is sort of the main alternative to Latex in my mind for the things I'm trying to do; perhaps there are better options.)
It would be more rational to output to HTML5, since there are insane amounts of HTML to X converters around (APIs and tools alike). PDF or Doc from HTML is utterly trivial at this stage.
I am very tempted to try to write my next publication in HTML. However, I seriously worry about things like footnotes, code examples, floating figures and references. CSS3 seems to have support for many of these, but I wonder how well the convert-to-PDF pipeline really works, and how flexible it really is.
It's bad enough if I have to convert my original source to some other format years down the line, but it is absolutely critical that I can at least create the initial PDF correctly.
And episode 8, "Sisters of the Sun"[1], covered Pickering and his "colleagues", several women nicknamed computers, namely Annie Jump Cannon, and Cecilia Payne.
If I were paying ~2400/yr and was given the option of ~1000/yr, I would think I've been grossly overpaying for the monthly option. In your shoes I would offer one month free for 2200/yr rather than 7 months free.
