They sent a company wide email asking people to develop applications for the OS, and receive a Palm Pre for free.
I created an app that simply turns off the screen, and called it a mirror app (because you could see your reflection). I really enjoyed my free Palm Pre.
I tried resurrecting it a few years ago but couldn’t find a replacement battery after the original died.
Great read, thanks for sharing! This means to me you are mature, sharing stuff instead of making obscure secrets from basic stuff existing at many companies <3
Many do that with Joplin.
If I was making edits more often, I might run into sync conflicts. But I mostly edit on my PC, then might make small edits to recipes while I'm working in the kitchen.
I really never thought of the app and I just went to the website.
Is there some reason to use the app?
But I've been using the website for over a year and don't feel like I'm missing out.
When working on the code, it's also very useful to access the history without having to open each ticket. Being able to hover a line, having the message of the commit which last changed it, and be able to say "ah ok, it was for this" is quite useful.
> I’m not staying long enough in this company to see them changing from Jira to something else, so I don’t care about the Jira dependence to understand commits
Isn't this a terrible argument in favor of "Fixes NNN" commits? Someone who care about the longevity of a versioned thing should care. If you don't care anyway, nothing matters much.
Honestly, this just sounds like we need better integrations with JIRA into dev tools. I'm not going to rewrite tickets in commits / PRs. That ticket has its own history, linked tickets, acceptance criteria, epics, related bug tickets, etc.
1. "How squash merge can break Git repos with submodules", about a situation where squash merges silently broke a repository: https://news.ycombinator.com/item?id=40846596
2. "Git: please stop squash merging!" giving some technical explanation about what squash merges actually are under the hood and how the misconceptions about Git leads to invalid "pros" about squash merging: https://news.ycombinator.com/item?id=40840572
My general preferences beyond that are:
- Opening braces on the same line (I see the article has examples where it's on a new line);
- Two space indent, no tabs
- No trailing white space. This should be automatically removed so it doesn't generate extraneous changes on commit;
- A reasonable line length between 80 and 120 characters, depending on the language. You need to be able to look at 3 files side by side without wrapping.
- Don't put the return type on a separate line. This is a really old school (K&R) C style
- Don't align function parameters with opening parentheses. Change the function name and you generate a bunch of changed lines for the parameters.
- No space before semi-colons eg for (i=1; i<100; i++) not for (i = i ; i < 100 ; i++ )
Every developer can control how those tabs are rendered to their preference.
So treating "get a response" and "get data from a response" separately works out well for us.