In 2008, GitHub’s developers could have opted to use git format-patch instead of teaching the world to juggle branches. Or they might have chosen to generate pull requests using the git request-pull command that’s existed in Git since 2005 and is still used by the Linux kernel maintainers today2.
I’m getting into stacked branches these day, but I should look into git request-pull too.
I write a lot every day, but I don’t publish a lot of it since I have this fear of being judged. But I have a lot of ideas and thoughts that can be boring for some people but maybe interesting for others.
I ramble about tools and workflows in Day One and my Zettelkasten. Those are private posts that are not necessarily useful to anyone, but I want to publish them anyway because I can see a history of my thoughts, which can give someone else an idea.
That’s what #DigitalGarden is about, but it is still different. Sometimes, I want to write a journal entry and be done with it. I don’t need a full-fledged Zettelkasten all the time.
Actually, I’m afraid of publishing these ideas, but as we have had success with open-source software in the last couple of decades, maybe open-source thinking can be a helpful thing to master, too.
What do I mean by that? Blogposts without much crafting and maybe even with a lot of grammar errors, but the idea is that I can write about something, then continue thinking about that idea in a new post, and so on. Maybe I’ll run into a conclusion and come up with something cool or ignore the whole thing at the end, but the critical point here is that I should flex my writing more, and my blog is still the best place for that.
Inspired by More people should write
I am still not sure if I need this or not, but interesting nonetheless.
Sonar is a beatiful (and native) Mac app for managing Github and GitLab issues. I used the beta in the last couple of weeks for managing GitHub issues and it’s really good. The high-level outline view changes how you manage issues.
If you use Hookmark, I also made a integration scripts for it which is pretty useful for linking OmniFocus/Things projects to issues in Sonar.
Sonar is a new native Mac app for viewing and editing GitHub/GitLab issues. It’s lightning fast and stores your tasks locally so viewing, searching, and editing is instant (even offline).
I was looking for something like this for a while now.
Interesting to see how people are using Org mode for journaling.
This is app uses text views to convert the text back to Org mode syntax: kind of a two way street implementation of having a UITextView with a controller which parses and creates rich-text ↔ plain-text.
There are a lot of good Git workflow patterns here.
Just because you know something needs JavaScript, doesn’t mean it still does. You can make better websites if you test those assumptions every now and then.
These sheets are like regular programs in many ways. Felienne Hermans, a veteran spreadsheet researcher, puts it very simply: Spreadsheets are code. She also goes on to show that they suffer from the same problems as real software.
I agree with this. We would be better off with a more “natural” update cycle on the Mac. It’s a slower-moving platform these days anyway:
Regardless of the motivation, the annual updates are more of a burden than a blessing to many Apple customers, including myself. I wish that Apple would drop the artificial schedule and let the major updates come more naturally. This isn’t just the attitude of a developer and so-called “power user”. Many “normal” users”, the proverbial moms, feel the same way. Actually, my literal mom told me she doesn’t like the ceaseless annual major updates either. She’s learned from hard experience that they’re not necessarily safe to install. Major updates can be very disruptive, creating new problems and wrecking old workflows. The press is always excited by major updates, because they give the press a lot to write about, but the public is not as sanguine. We occasionally need a break of 23 months, or more, from computing disruption. That would be another Snow Leopard.
Related to this: The Mac, The Myth, The Legend: How Snow Leopard became synonymous with reliability
Bookmarked “Scarlet“:
Scarlet is a personal issue tracker that saves to a file that you can include in your project directory, or anywhere you prefer. No accounts, no cloud services, no syncing, no third-party integration. Just a simple place to file away your project’s to-dos and close them when they’re complete.
Other than Apple’s official documentation, what are the best sources on learning AppKit?
I constantly tweak my workflows this time of the year. I usually provide tools for others—that’s what I do for a living—but I also have to keep my knives sharp.
This year I’m tweaking two things.
Take better notes while watching a video.
1. I set up a YouTube channel piped into DEVONthink using RSS to download videos automatically.
2. I can use DEVONthink’s Annotations feature locally to insert timestamp-specific notes for the video.
3. I can export the annotation into Craft and create “permanent notes” in my Zettelkasten.
Moving my Zettelkasten over to Bike.
I like to think about my Zettelkasten being a large outline. Keeping it inside Bike could be beneficial.
I’m trying to mimic the analog Zettelkasten (or Antinet).
I won’t use an analog one since I like the digital one’s benefits better, but I also want ideas from the analog one.
I’m a programmer and I use my Zettelkasten to understand coding concepts. I have some code snippets stored in SnippetsLab, so it’s easier to link to those from my Zettelkasten outline than keeping them on paper.
I can nest notes under each other.
I can easily link notes together thanks to the Bike and Hook integration.
Disadvantages
I don’t have backlinks, but I’m not sure I need that inside a Zettelkasten.
I built a completely responsive 12-6-4 columns grid component built on top of GitHub’s ViewComponent gem and the CSS Grid Layout.
Here’s a demo:
Entering date and time values into an application is hard. I combined these two interactions into one UI to make things easier. Here’s how I did it.
Jason Fried wrote a post about doing remote work, with the expectations of local employment. This post resonated with me very well since I had a couple of weird interviews lately. Just a side note: yes, I quit my current job as a Ruby backend developer at TerraCycle about three weeks ago, and I’ll start working as a frontend developer/product designer at Nearcut on March 10th.
There are still companies that refuse to accept that remote work is a viable alternative. They want you to be in the office because “this is what we did before the pandemic, and everything should be back to normal soon.” No, nothing will be like before, and companies should embrace that, not deny it.
Not everyone’s like that. Even big ones consider remote work a viable alternative but don’t have the hiring process and experience to work like that, so they’re relying on old habits.
The enlightened companies coming out of this pandemic will be the ones that figured out the right way to work remotely. They’ll have stopped trying to make remote look like local. They’ll have discovered that remote work means more autonomy, more trust, more uninterrupted stretches of time, smaller teams, more independent, concurrent work (and less dependent, sequenced work).
I’m interested in what COVID-19 will do to remote work because, seriously considering remote work is one of the positive changes of the pandemic that happened in many workplaces. People were forced to work from home. Many companies figured out how to do this successfully, and they don’t want to throw out this knowledge because “everything will be back to normal.”
Jason also writes about native platforms:
Porting things between platforms is common, especially when the new thing is truly brand new (or trying to gain traction). As the Mac gained steam in the late 80s and early 90s, and Windows 3 came out in 1990, a large numbers of Windows/PC developers began to port their software to the Mac. They didn’t write Mac software, they ported Windows software. And you could tell – it was pretty shit. It was nice to have at a time when the Mac wasn’t widely developed, but, it was clearly ported.
When something’s ported, it’s obvious. Obviously not right.
Stuff that’s ported lacks the native sensibilities of the receiving platform. It doesn’t celebrate the advantages, it only meets the lowest possible bar. Everyone knows it. Sometimes we’re simply glad to have it because it’s either that or nothing, but there’s rarely a ringing endorsement of something that’s so obviously moved from A to B without consideration for what makes B, B.
Maybe Basecamp should create a Catalyst version of HEY for Mac from their iOS app, which is quite nice, instead of having a cross-platform Electron thing on the desktop called a “native Mac app.”
Nowadays, I use SVG icons everywhere, but preparing them is quite time-consuming. This website could help pick and use nicely designed ones for your next project.
As I refresh my online presence with a new avatar and a new Dribbble profile, it occurred to me that I don’t have a page, which I can hand to somebody, and he/she can see what my work is all about. Not a portfolio, but a more superior page than a simple “About Me” in WordPress.
So I built one, featuring some of my work I did lately and, more importantly, the first web development tutorial I promised a couple of months ago. I plan to extract this article into a separate mini-site just for these tutorials, but for now, it nicely complements my “About” page.
Anyway, check out my work!
It was a long time since I posted anything on Dribbble. In the last couple of years, I did so many exciting things, but I haven’t shown them anywhere; I did show some bits and blobs on Twitter.
Since I like to think about UI interactions and building tools, I should have a platform to show the results. And Dribbble is excellent for that. So from now on, I try to post new stuff I’m working on.
Checkout my Dribbble profile →
(Feedback is always welcome.)
Ha fejlesztő vagy, akkor az alábbi oldalt tedd el a bookmarkjaid közé és kezdd el alkalmazni az itt tanácsolt dolgokat:
If you haven’t given much thought to what makes a great Git commit message, it may be the case that you haven’t spent much time using git log and related tools. There is a vicious cycle here: because the commit history is unstructured and inconsistent, one doesn’t spend much time using or taking care of it. And because it doesn’t get used or taken care of, it remains unstructured and inconsistent.
Madarat tolláról, fejlesztőt git history-járól.
Replying to: MuellerSimhofer:
As user I’ve seen Spotlight implementations for document based apps (usually just using NSUserActivity), but the problem is that they usually duplicate results. You get one result from Files and then another one from the app’s index.
Also keeping the index up-to-date seems hard, since I can delete files outside the app, but the app’s index still contains it: I have to start the app, to get the index updated. I’m curious how you guys can solve this for MindNode.
Replying to: MuellerSimhofer:
I haven’t implemented anything like that for myself, but Spotlight indexes the Files app anyway. What’s the point of building a custom index?
