1,316 karma · joined January 19, 2017
This is why CIELAB was used, because like the linked HSLuv color space, you can increase brightness across hues with the same perceived brightness shift.
The fact that CIELAB can covert to RGB values outside the usual range is fine, e.g. negative values are fine in wide RGB color space.
I had this code that lets you choose a brighter or darker variant of a color palette, and initially bright yellow looked awfully close to white, so I decided to do this conversion through CIELAB (similar to HSLuv). Some unrelated code was storing these colors in the cloud using hex format, and clients would sync these colors back and forth with the cloud.
Usually, everything worked great. I had no problems, however a couple of users started emailing to complain that their colors had ‘disappeared’! As in - the stored colors had become transparent. I spent at least a few hours auditing syncing code, but found nothing.
A few weeks later I stumbled on the issue by chance: if you select dark green (this specific color configuration only), the color would eventually become transparent.
The thing is - some platforms (e.g. iOS) support wide color, which use RGB values outside the 0 to 1 range. Green would go through the CIELAB brightness conversion, and come out with a negative number for one of the RGB values. This is OK, until you convert it to hex and send it to the cloud for syncing... naive color -> hex conversion will freak out with negative numbers. This got sent to the cloud, and later on, the cloud would send this back to the client, which would use it as a source of truth (and so dark green colors would disappear).
The fix was to write a less naive hex converter. This was a few years back, perhaps by now most color -> hex libraries consider this case.
If I need to use stackoverflow, these days I make sure I do a few things:
- read a number of answers, comments included. Just because an answer is accepted doesn’t mean it’s the best one
- read API docs for anything I’m unfamiliar with, and make sure I understand how the solution works
- never copy paste; instead use the general idea or concept to rewrite a solution in a safe, future proof manner
- if an answer works but doesn’t feel like the right solution, be prepared to do my own research to find a better approach
Hopefully this results in a better engineered product, but one of the main benefits is learning and expanding knowledge of APIs/techniques.
It would save time for tech support workers too; no need to vet very tech capable callers for things like ‘have you tried turning it off and on again’. So theoretically, the call wait time might even reduce for callers with simple/obvious questions.
There are probably some details to iron out and problems to solve, but the basic idea seems pretty feasible to me.
I opened the PDF to find not one, but three separate tasks. Completion of all three was expected, with an estimate of about two hours each. One of the tasks was to replicate Apple’s ‘Reminders’ app in its entirety, backend sync functionality included. Another, a task requesting Visual Studio (iOS devs have no need for any experience with this).
I promptly replied declining to continue the interview process. If you’re ever in a similar situation, interviews can sometimes tell you more about the company than they can learn about you. Good chance I dodged a bullet, and could have been working for someone setting highly unrealistic client deadlines, with the expectation that I can build something in any technology proficiently.
Apple’s gesture for this requires starting at the edge of the screen, but Instagram allows you to start swiping anywhere.
I’d hesitate a guess that without this difference, the ape wouldn’t have been able to browse Instagram nearly as easily.
I get that there’s workarounds like changing the redirect after Google checks it, but there’s solutions to this too (like running checks every so often to ensure the link redirects to the same domain).
The OS could then automatically apply this to website load behavior, and apps could request permission to receive this information too. E.g. Spotify could pre buffer more of the playlist you’re listening to, and news reader apps could load a few articles in advance.
Physics turned out a little more dull than I expected (I wanted something with more creativity), and an app I’d started working on as a hobby turned into a full time income, so I started pursuing this instead (https://classtimetable.app).
I took a few full time iOS jobs, continued to improve my engineering skills, and I’m currently working for a top five tech company on a popular iOS app.
Physics certainly taught me a few skills that I use on a daily basis - math and problem solving are good examples. I didn’t move to software specifically for the money, but comparatively physics seemed a little more dull, and software seemed to have new and exciting opportunities (like the app that I started building as a hobby).
Spotify doesn’t just forfeit 30% of their App Store revenue, they pay this directly to Apple - so the relative handicap is doubled.
In general Swift’s type inference can be slow, and seems to have bad time complexity. I suspect that for non trivial closures Swift falls back to requiring explicit typing so that type inference speed doesn’t become too much of an issue.
You can actually improve compile times somewhat by adding explicit typing for complex statements. There’s a compiler flag for logging compile time per function, and for large projects I’ve used this to identify and add typing for problematic lines (sometimes these lines each contributed to a few seconds of compile time).
- It could be nice to add 'bottom' mode support, where the menu appears above the menu indicator. At the moment the menu requires users to reach to the top of the screen, but the one-touch interaction could become even more accessible if the menu was at the bottom of the screen.
- There's one point of detail that is a really, really nice solution for a problem that lots of apps have: "What I ended up doing was choosing a light or dark tint for the menu title text and buttons based on the area of overlap with the underlying view, and the darkness of that view". The result looks fantastic. Hey Apple devs, if you're reading this... you should add system level support for this! i.e. dynamic contextual blur effects, I guess with some kind of callback or content effect to adjust content color as the underlying blur type changes.
- Although there's a lot of attention to detail already, the one-touch edge drag seems a little jerky to me. I'm not sure whether it's just the video, or the use of a Timer to accomplish this (I'd suggest a CADisplayLink, especially for supporting faster refresh rates on new iPads), or because every intermediate item immediately highlights as you scroll through - but perhaps disabling highlighting/selection during this auto-scroll interaction would help.
Overall it looks really great - thanks to the author for sharing this!
It made me wonder why network libraries don’t do this for the actual requests by default (or perhaps they do?). I’m sure there are some cases where simultaneous requests are intentional, but it seems like this would be infrequent.
I wonder if this could be related somehow to the Dunning-Kruger effect? https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...
I’ve run into the author’s problem a few times, and I’d like to think that this is just a bug or behaviour detail that a future Swift version could correct. Swift hasn’t quite matured fully yet, and this is a great example of that (these examples are becoming fewer every year though).
In general the country switching experience seems pretty sub par: if you had just purchased a year long app subscription (I believe some apps can offer that), your options for changing country would either be to forfeit your purchase by calling up to terminate the subscription, or wait an entire year for it to expire...
I’m a little surprised that a service with 40M subscribers doesn’t seem to consider that users might do this.
Up until now it hasn’t been possible due to the restrictive API. I’ve looked into the new shortcuts and Siri API docs and although the beta documentation is sparse, I’m confident I’ll be able to develop a natural, first class Siri integration.
Unfortunately, it won’t be trivial to implement (at least to do well). It probably won’t be done before the iOS 12 release, and I’m hesitant to start working it just yet due to the sparse beta docs.
Over the next year or two, I think there will be some great Siri integrations built. Hopefully, users discover and use them :)
Like the article mentions, being able to answer every question means that you’re not pushing yourself. I spent the majority of my time attempting questions that I didn’t think I’d be able to do, while many classmates would spend their time attempting questions they thought they would know. It forced me to constantly ‘solve hard problems’, and become better at doing so. A lot of the time I couldn’t successfully answer the questions I attempted, but in doing so I’d learn a lot anyway.
The article content is great, but I’d add that practice is an essential part of learning to solve hard problems. If you’re studying too, I’d really recommend the learning technique I used, at least to some degree - it will help you become a quick learner and good problem solver.
• run a beta test group. These users consist mostly of users that have emailed in with feature suggestions or bugs. I ask them if they’d like to join the beta (e.g. they can check their bug is fixed). I frequently get great feedback from a few of these users.
• fiverr.com. Shell out $100 spread across a range of testers, and give them all slightly different briefings. Some feedback is terrible but there’s some gold there that’s really worth far more than $100.
• learn how to test your own product. It’s hard to do well, but you can learn. It’s a valuable skill that can really set you apart in a regular engineering job too.
• used phased releases. Pause the release at 1%, give it a few days for any minor issues to roll in and fix these before releasing to 100%.
With legacy style result callbacks, you’ll have both an optional value and an optional error returned - this corresponds to four possible states. If I’m using an API returning this, I have to think about two cases which probably won’t happen (neither an error or value, or both an error and a value). I’d like to think the API I’m using wouldn’t return those states, but since it’s not typed as such then code I’m writing should probably handle those cases gracefully.
By using a result type as per the article, it is well defined that only two states are possible. This pattern is a really nice one, and is a great use of Swift’s associated value enums.
Apple is usually quick to deprecate (which does have its own advantages), but given that a large part of their own tech stack is built on Objective-C, I think they'll play the long game here. I would be surprised to see it deprecated before the end of next decade (although I wouldn't put it past Apple either...).
However, to say that Swift is a regression over Objective C seems very short sighted to me. Can you imagine if Apple continued with Objective-C? There would be no way to reverse decade old decisions that simply aren't the right decision anymore. Every new feature would need to be built on top of code from 1984. Swift was very future focused from the get go, and is a bid to ensure that developing for Apple devices in 2025 is not an archaic mess.
Like anything new, it's not perfect at first. That is the world we live in now. However, Swift is getting incrementally better at a very good pace. There are some reasons left to prefer Objective-C right now, but I'm sure that in a few years these reasons will be far fewer.
My own opinion is that I'm much more productive writing Swift, after spending a similar amount of time with each language. If you think the same is true of Objective-C, then that's great - there are certainly still some upsides to developing with Objective-C. However, to say that Swift is a mistake is something that I can't reason with, since it's one of Apple's most forward thinking decisions to date.