If I end up with multiple features or abstractions in one change (equivalent to the “dirty repo”), jj split works very well as an alternative to the git add/git commit/repeat workflow tidying up one’s working copy.
42 karma · joined February 7, 2011
If I end up with multiple features or abstractions in one change (equivalent to the “dirty repo”), jj split works very well as an alternative to the git add/git commit/repeat workflow tidying up one’s working copy.
I found when using jj it worked best for me when I stopped thinking in commits (which jj treats as very cheap “snapshots” of your code) and instead focus on the “changes”. Felt weird for me at first, but I realized when I was rebasing with git that’s how I viewed the logical changes I made anyway, jj just makes it explicit.
jj auto-rebasing doesn’t matter until you push changes, and once you do it marks them immutable, preventing you from accidentally rebasing changes that have been shared.
But most of all I think the overall simplicity of the language is really what’s standing out to me. So far I think the lack of ad-hoc poly and macros are a plus - it really reduces the impulse to write “magical” code, or code with lots of indirections. In the past I’ve definitely been guilty of over-abstracting things, and I’m really trying to keep things as simple as possible now. Though I’ve yet to try Gleam with a large project - maybe I’ll miss the abstractions as project complexity increases.
I suspect Gleam will be a great language for small to medium sized projects written with LLM assistance (NOT vibecoded) - the small language, strong typing and immutability gives good guardrails for LLM-generated code, and encourages a simple, direct style of programming where a human programmer can keep the whole structure in their head. Letting an LLM run free and not understanding what it’s written is I think where projects run into big problems.
Apps that are built for iOS 7 get the new shiny keyboard and some different behaviour when run on iOS 7, but can still run fine on older versions of iOS if the app developer is willing to support older versions of iOS. This is done by setting an option called "deployment target" to an older iOS version when building in Xcode (and testing a ton on older versions of iOS, and not calling newer APIs on versions of iOS that don't support them).
So this announcement means Apple is dropping support for older versions of Xcode (with older iOS SDKs), but older versions of iOS are still technically supported as long as you're building with the iOS 7 SDK.
I think this time I'm going to actually do something. Probably not ditch Google entirely, but ensure I'm not entirely dependent on them.
If sales actually pick up on iPhone, I think it'd be a good project for me to learn the Android SDK.
I'm hoping to get some feedback on my second iOS app, Scrollendar. My first app, LessonLog, is pretty niche (teachers with iPhones), so Scrollendar is my first app that I feel has a chance at any kind of popularity.
Some background: I finished Scrollendar v1 and got it on the App Store last May. The first version only took about a week to build, and although I was fairly happy with it, it had some rough edges. Having an engineering background, I figured I'd leave the marketing until after I submitted a few updates and got things a little more polished.
However, I made two assumptions that (unsurprisingly) turned out to be false:
1. I greatly underestimated the amount of time needed to fix the rough edges and be really happy with the final product. I ended up adding the scrolling day view, which ended up being a lot of work, then I rewrote the entire backend due to deficiencies in NSDate and EventKit. What I figured would take a couple weeks took over a month.
2. I greatly overestimated the amount of people that would find Scrollendar without any marketing. I wasn't expecting many people to find it through organic App Store searches, but I figured at least one or two people would stumble on it each day. What actually happened is after an initial spike of six whole downloads the first day, the daily downloads quickly dropped to zero. I haven't had a single purchase in the last 30 days. This is even less than my niche teaching app LessonLog.
So I'm hoping to get some feedback on the app and the website (scrollendar.com). I'd also love any tips for a first time mobile app marketer. I've poured over every HN post that has anything to do with online marketing, and most of it comes down to: - have a viral component to the app (not really applicable to Scrollendar) - build a following online with a well written blog and great social media posts (I have neither right now) - build a great website with lots of useful content (like bingo cards) to drive search traffic (again, not really applicable)
So basically, my online marketing plan boils down to: e-mail mobile app review sites. Is this sufficient? What else can someone in my position do?
Thanks in advance! Scott