Ask HN: What do you regret you didn't know when programming for iOS or Android?
What do you regret you didn't know when started programming for iOS or Android?
Image loading was often a huge source of crashes due to out-of-memory errors and doing it properly wasn't trivial [0]. Libraries like "Glide" and "Picasso" solved this.
Using the camera hardware was awful. Device manufacturers would implement things differently, and break the camera API unexpectedly. Only recently [1] are we starting to see sane, consistent camera APIs.
Making network requests felt extremely clunky, and the platform JSON implementation wasn't performant, or easy to use as you had to manually parse everything. Retrofit [2] made talking to REST services much easier.
I could go on and on, but I'm sure there's plenty others here who can do that here. These days Android development is much, much more enjoyable. Kotlin has pretty much replaced Java in the Android ecosystem, and there's great reasources around on how to architect your app to make everything testable and easily scalable such as the architecture samples [3]. I've worked on a few React Native projects in the last year. I'm not a fan of it, but I definitely see the industry heading to some cross platform solution eventually.
[0]. https://developer.android.com/topic/performance/graphics/loa...
[1]. https://developer.android.com/training/camerax
Very few companies have ever failed because their tech stack didn't scale well.
If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten.
Plus it will take a while for the native version to get feature parity with the cross-platform version, and you typically can't roll out the native version until you have parity.
I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.
On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startup to the size of any of these companies, I'd say you're doing pretty well on the technology front.
Kind of like how Twitter had to do a major rewrite from Rails, but Rails got them to the point where they needed that rewrite.
So cross-platform solutions on mobile indeed seem to fit most-if-not-all of the 'normal' use-cases, assuming there's server resource available. The Twitter/Rails example is one perfect illustration, and there are many such examples throughout big names we know today.
1. JSON parsing
2. Network calls
3. Background downloading
4. Notifications
5. Camera access
6. Password/contact/code auto fill
7. VoiceOver
8. Web Views
9. JavaScript bridging
10. Encryption
11. And many more
Almost every app needs some combination of those and in some of these cases you’re forced to use a native solution. What ends up happening is that a significant amount of developer resources gets wasted bridging many of these things with massive bug logs to go with them. It’s why at this point I refuse to do anything but native in my career.
Point well taken! If I may ask, would you say that
1. it's a problem inherent to developing on mobile (whatever the underlying reasons, hardware iterations, idk), and that OS APIs are indeed trying to solve as best they can (it's just a hard problem),
or rather
2. that it's a problem somehow created by OS vendors of their own volition? (a.k.a "evil microsoft walled garden", cue "Apple's take on that" and Google's similar moves for Android and we think Fuschia) In essence a business-driven reality.
I actually don't care about "evil" (hence the wording, it's funny) when it's just business strategy; my deeper question is really about the problem space.
Like, is this forever (native versus cross on a fast-iterating platform), is this industrial politics or technical limitations, could some other platform do it "better" (thinking of SailfishOS, or the Linux phones like the Pine project etc.)
Well if they're doing it like that, it's indeed not much better than hara-kiri. There are better ways :)
How you do it is incrementally, avoiding too-major changes at once, and progressively moving from codebase A (cross-platform framework) towards codebase B (new native thing). But it happens at the integration level, i.e. you build with increasingly more % from B, but during the whole A->B transition it'll be a hybrid build.
E.g. part Flutter / part native.
1. You begin with "let's take camera stuff out of Flutter and re-implement our related features using native APIs": this instantly makes two apps (iOS, Android) with 90-99% code in common, just a fork to handle camera APIs separately (by the way, the state of API affairs often forced you to do this to some extent for any non-trivial use-case; I'd wager it used to be the state of most feature-rich apps in the 2010s).
2. Then you proceed with another component of your app. Rinse and repeat until you've got 90% from B and the remaining stuff is structural.
3. All that remains is to remove Flutter entirely from the equation and rewrite your core app logic: what glues all of the above components together; all of which at that stage are already rewritten for native and tested independently (critical to your success).
Along the way you never truly break UX, it's more of a classic "ongoing development" thing with details changing here and there, and hopefully better UX each step since your move to native must be motivated by something worth it for the client-side (otherwise it's likely your server API model that needs refactoring).
That's how the now-default-consensual approach to how you change stacks without breaking UX, nor your company. Full rewrites on wholly new tech is just asking for cataclysm: you literally do that to yourself, to your own code and users. It's also the only reasonable way I know for small teams, one-man shows, etc.
Just out of interest, are there any clear examples where this happened, ever? Can anyone name any?
What I mean specifically is - a company with a well known product that was growing in popularity but then hit a ceiling because of technical scale issues and couldn't support any more customers, growth halted, and they couldn't fix it in time to keep the momentum going (or got overtaken by a competitor) and failed?
The best options available for most Apps today (even if just for a single platform) are typically React Native or Flutter. With their React(-ish) UI approaches you can both quickly build and iterate in the future.
SwiftUI is not ready for most uses (I've shipped a small but non trivial app https://apps.apple.com/us/app/pattern-maker/id1484249212 and was surprised by how many bugs there are for very standard things and how many hacks seemed to be required). Jetpack Compose seems to be at an even earlier stage. I expect both will be great but probably not for some time.
Then there are several kinds of workflows that are quite doable as mobile Web. One just has to take into consideration that 3G isn't broadband, nor a mobile display a last generation 25" screen.
PWAs will keep being pushed by Chrome team, alongside Microsoft, and I wouldn't be surprised to see a Kotlin/Native variant of Jetpack Composer by Google IO 2020.
For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers.
At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to implement native expectations for controls in the first place, much less keep up with native functionality across platforms.
Are you talking about Dart?
If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is.
It's just so sad. And to think that the team behind flutter purposefully chose it after considering a bunch of other languages.
I personally don't feel that dart is tied in any way to flutter. It was originally meant to be compiled to js, and that shows in vm architecture, but that doesn't look like a con.
You can write idiomatic Dart code that won't run because Flutter asserts crash it at runtime. And you fix it by writing code that the Dart compiler complains about but lets you run and it works (even though it shouldn't). Is there another compiled language where this is the norm?
What's the point of dealing with a half baked ecosystem when there are much better languages available?
I'm currently writing a cross-platform app in Flutter that is launching soon, and I found that the developer experience is world-class and I've had very few issues so far. The language is incredibly easy to pick up with close to zero overhead if you are a somewhat competent programmer as it is essentially a very lightweight OOP language. My main languages are otherwise Go and Rust, and picking up Dart was not difficult at all for me and I don't think you need to be a wizard to figure it out. I suspect JS devs will find it even easier to pick up as many of the constructs are similar.
It took only a couple of days to get up to speed with Flutter-specific functionality as well as the native API bindings, and I was already writing production code for the app the first week of exposure to the language. The UI framework is declarative and very easy to reason about and design, and the tooling is also incredibly seamless and easy to use, although I do agree that it needs some polishing as there are some edge cases that you sometimes need to trawl the Github issues page to fix.
Yes, sometimes it is frustrating as there are some things that are lacking in the standard library, but the third-party library scene is picking up and you can do 95% of what you want to do without major issue. I'm convinced that Flutter is going to become bigger in the future and is going to cover most use cases for all but the most performant apps and perhaps games.
Flutter is a breath of fresh air after building and maintaining the same app over and over again for several platforms.
I haven't worked with the platform for 2 to 3 years. In my old job we had massive problems at the end hence we switched to native (we were an agency).
Problems we had:
* Deploying to devices was painfully slow compared to native stack.
* We all had Macs and the tooling (Visual Studio for Mac/MonoDevelop) was pretty bad compared to Android Studio.
* Wrapping 3rd party native libs was a pain, if not impossible. Especially in a stressful agency environment.
When we heard about the acquisition of Xamarin by Microsoft I was hopeful things would change to the better. But month later they rebranded MonoDevelop and focused on integrating Azure.
Did it get any better?
There a release event happening next month, https://visualstudio.microsoft.com/vs/mac/event/
From the comment 2 months ago https://www.youtube.com/watch?v=QYkTXJ2TuiA&lc=UgwBlx_R3eL4k...
Not true! Having gotten into iOS development over the past couple of years, I’ve come to realize that seemingly no attempt has been made to actually clear the cobwebs on this shiny, relatively new platform.
For example, SwiftUI is just an abstraction layer for UIKit, which itself is (keep me honest, HN) an abstraction for some mishmash of Cocoa, Display PostScript and Metal. Bits of NeXTSTEP are everywhere still, even when using Apple’s latest and greatest programming paradigms.
Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.
I guess that's what Flutter is doing (for both iOS and Android).
How does it do this as opposed to adding yet one more layer? Does it somehow get beneath all the cruft mentioned?
It has some downsides – they had to expose a lot of accessibility features on top of that using platform APIs – but it's quite nice when you are a developer, as you can Cmd-click on anything to learn how it is drawn, and use the same tools to build your own widgets if you need.
I'm not completely sure about it, i just now it from listening to some talks.
Seems like it will be solved 'soon'
The problem with this is that it is an enormous task and they have barely scratched the surface of it.
Flutter is hardly the first reimplement the world GUI programming environment that tries to match the existing first party environment in terms of look and feel. Java swing was pretty much the same idea 20 years ago, and probably had more investment and momentum behind it than Flutter does today. While I can think of a number of swing success stories, I don’t think java swing as a whole was successful in what it set out to do.
It's an enormous task that never ends, too. Flutter has to continually keep up with UI/UX changes that Apple makes. Without enough momentum there, the devs using their platform are going to have apps that appear/feel old, which tends to be a marketing negative for Apple users.
-Revamped permissions
-App packaging/name spacing/consistent installation
-IPC was redesigned as asynchronous Intent blobs on Android
-Urls becoming first class citizens at the OS level
-More consistent background app apis (and eventually better ways to track them)
Starting anew is over rated. It’s sometimes the right answer, sure, but it’s just one possible answer. iOS benefited enormously from being immediately familiar and approachable to existing OSX devs, and would have taken another 5+ years to develop from scratch without leveraging its OSX heritage.
Meanwhile Android was in a crash emergency race to relevance for the first 5 years of its existence. If they’d taken the time to do everything right the first time, they could have ceded Microsoft enough time to get their Windows Mobile act in gear.
So legacy is a thing for a reason, taking one opportunity very often means giving up another.
A lot of people are recommending using cross platform solutions. As a hobby or learning exercise, go for it! As someone who has a career across many projects working full time as a native iOS and Android dev, I can say these solutions are generally avoided. They are good for prototypes you don’t plan to maintain long term, I’ll give them that.
I know it’s cheesy but my only regret is I didn’t go all-in on mobile sooner. I have been on a constant upward career trajectory since the day I put my first app on the store. Get an app on the store as soon as you can and if it gets traction listen to feedback and update it. If you’re early in your career this will be the only thing on your resume that matters. I highly recommend you start with iOS just because the tools are more friendly for beginners. Watch WWDC/Google IO sessions and keep up with the latest. However it’s best to keep a healthy distance with things that only support the newest OS. For instance I wouldn’t build an app in SwiftUI yet but I follow it like a hawk because it’s likely to be the only way Apple platform apps are made very soon. Closely follow VR/AR frameworks and machine learning. Those will become must-know this decade.
Mobile dev is so rewarding! Every developer should at least dip their toes in.
As far as learning, I think this Stanford course is the best way (though not for those who aren’t absolute beginners to programming). I notice it hasn’t been updated lately but it should be current enough https://www.youtube.com/watch?v=TZL5AmwuwlA
On Android, setting up for development is a bit faster but the actual development story is so, so much worse. Kotlin improved things a great deal and Jetpack improves it further, but it still has such a long way to go. You’ll spend inordinate amounts of time researching the “right” way to do things only to find that there really isn’t one, but instead several ways with varying levels of wrongness with different trade offs. Even mundane things will be a source of trouble and you will likely have to make concessions in your UI design to work around Android SDK awkwardness.
If I could just have UIKit on Android I would be a much, much happier Android dev. Hoping Jetpack Compose improves the situation but I’m not holding my breath.
From what I've heard Android is unusually bad for this but this particular sentence resonates with me in terms of basically everything ... though that may be because I do a bunch of deployment/ops stuff which is generally entirely made out of "choose your own petard to be hoist by later"
Unfortunately GUI is particularly fiddly and difficult to write the double interface for, since you get a "thousand words is one picture" problem: it doesn't reduce well to text.
I started Android programming from the command line using make/ant and testing on a device because I didn't like Android Studio. This ended up wasting a lot of time and energy over the years as I had to integrate more 3rd party libraries (including Google's own crap).
Same thing for iOS. I didn't like building GUIs in Interface Builder so I did everything in code. Over time as iOS devices came in different sizes, this became harder to do properly. I should have given in early and learned to use Interface Builder, auto layout, etc.
The constraints are impossible to code review in XML since they refer to elements by IB ID which is essentially obfuscated. I don't understand why IB doesn't let you give the elements their own human-readable IDs.
For smaller apps, with a team of 2-3 people, IB is fine....
Ignore the framework. Write your app how you want to write it, then attach it to the framework as needed. Don't restrict yourself to what the framework supplies or how it thinks about things.
It'll dramatically decrease craziness in your core logic in the long run. Framework versions and bugs can lead to strange lifecycle callbacks, weird interactions between the N flavors of how to build UI components, etc, and if your core logic is chopped up to deal with all of this it can become very hard to make important changes. Such as updating to a newer version of the framework so your app isn't removed from the stores.
It'll pretty much always be more up-front code and work, but you'll be left with a far clearer system in the end.
This is a general software design principle that allows for your UI to be free to change without affecting your core logic and rules, while also making all of your code more unit testable.
Android lifecycles are probably the main target of my comment tbh. They're abysmally complex and make any kind of state management incredibly error-prone.
As a tradeoff for that complexity and losing a lot of control, if (and only if) you go all-in on them, you get decent state reviving after process death, which can do really slick things like "app crashed" -> it just appears to go back one screen.
Instead, you can write your app as e.g. an in-memory singleton somewhere. You can even do that in a different thread if you want, leaving your UI impossibly smooth (at increased risk of "tap x" -> "nothing happens"). Design your own lifecycle that makes sense for your app (which probably looks very little like the Android lifecycle, especially when you throw in fragments...) and trigger/wait on the external world of the Android framework as needed. Odds are pretty good that you'll take multiple things from Android and combine them into one in yours, and potentially vise versa (e.g. multiple actions from your app become view updates in a single activity, rather than multiple activities. or do everything in one activity, it's often far better performance anyway, and much easier to control in fine-grained ways. importantly, your core logic doesn't care, unlike if you put that logic in the activities).
I also regret not buying a book explaining all the concepts in as simple a manner as possible. As a semi-amateur programmer, I feel like most of the documentation is meant to refresh the memories of people who have been developing apps for years; they're extremely beginner-hostile.
For mobile development, this is why Expo was so crucial for me to understand how React Native works.
And I need to see diagrams of mental models, though practical examples help solidify that. So one challenge with writing documentation is knowing what your audience needs. A better taxonomy of documentation would help solve this. For now, here is one I like based on https://www.divio.com/blog/documentation/
- Tutorial: A walk through how to learn the basics as you build something.
- Explanation: Showing the mental model of something
- Guide: A walk through how to solve a specific problem
- Reference: A comprehensive* listing of the API capabilities and how they are used.
-------
If anyone knows of some good tutorials or explanations of mobile programming with React, I'd be grateful for recommendations.
As much as I criticise Microsoft at least they have stuff like this: https://docs.microsoft.com/en-us/windows/win32/learnwin32/le...
Yeah, really agree with that; I'm not sure about the state of Google, but the word 'beginner-hostile' is really an exact state of Apple's documentation (well I'm touching AppKit not UIKit, so that's a factor too but...).
Coming from a web background, almost every web framework had a starting point from the documentation or at least some concept documents: Apple's documentation is almost non-existent. The best documentation I could find was the archived ones from early 2010s, and those were not really helpful at all.
I did know Apple's dev experience isn't really great... but what I did not know was that learning Apple's APIs/conventions means watching three and four WWDC videos that briefly touch the API for about two or three minutes, learning two languages together(Swift & Objective-C -- which actually wasn't really that awful for me b.c. I already knew much about ObjC & message passing due to my interest in various (elegant) PLs), & searching for other people's personal projects from GitHub.
Seriously Apple, improve your documentation. It's just plain awful.
The problem isn't that they're providing documentation which is good but only appropriate for a narrow audience. The documentation is just bad: it misses out things that need to be said.
Then I regret looking into Nativescript, because it was pretty buggy.
Then I regret not knowing about Flutter earlier.
THEN I regret not knowing that Flutter is pretty buggy as well.
Next step is me trying to learn other frameworks, like Cordova or React Native. I wonder what my regrets will be.
https://github.com/nolanlawson/pinafore
Runs better than most native apps.
The one PITA for me is state management, but once you understand how to solve that using BLoC or Providers then it should be relatively usable
1. Problem with Cupertino theme on Android - https://github.com/flutter/flutter/issues/42988#issuecomment... -- only point 1 from this post matters, because point 2 was resolved by a helpful person below the post. But point 1 is still unresolved, and it looks bad.
2. Flutter runtime simply crashes on some mobile phones when loading the app. I've released an app on old SDK, and with every update of some minor thing + SDK I'm getting reports about new crashes from people who rated the app 5 starts on older SDKs, because it was working for them earlier. I've tried to report it: https://github.com/flutter/flutter/issues/43240 but my issue was grouped with some unrelated problem, and my questions were ignored.
3. I think the x86 codegen in Flutter is sometimes buggy. I've used a ZIP compressor/decompressor library written in pure Dart and it sometimes crashed in random location after using the library. I've tried to debug it but there was no pattern for the crash. The crash also was happening on the system level (SIGSEGV) instead of simply throwing an exception that would be catchable by Dart. When testing on the mobile phone, so when ARM codegen was used, I've observed no crashes and no problems when using the archive library.
4. Google AdMob has poor support for Flutter. The official AdMob lib doesn't support native ads, and is incompatible with widgets that draw an always-on-top layer, like Drawers or Action Buttons at the bottom right corner of the screen. It IS possible to finally work out the solution by using some thirdparty library which uses AdMob in a hacky way, but I would expect something better for one of the most crucial Google services like AdMob.
5. Until recently there was no support of Cupertino theme's i18n. I had to manually translate all texts of Cupertino theme to a different language (like 'copy', 'paste', etc).
I've released two apps in Flutter but I'm afraid to update them, because something always breaks after update.
All software has bugs, and the less amount of layers to debug the better.
Oh your camera gives you NV21 frames, but the hardware VP8 encoder only accepts I420? Makes perfect sense.
Oh, we don't actually let you query what format the encoder expects until a later API than you're using. Just try them in a loop until one doesn't fail, makes perfect sense.
The camera was a party too, added a listener for Camera session events and the app crashed. Yay.
All of the MediaCodec APIs were quite powerful, but did nothing to "keep the easy things easy" or hide much of the lower level hardware details from your app.
This is kind of a theme in Android (or was... my experience is slightly out of date right now).
As mentioned by "McDev" in what is currently the top post on this thread it is a good idea to use time-tested third party libraries to do things that you'd kinda expect the OS to handle naively because the OS level APIs don't do a great job at abstracting any of the details away even for things that you'd think you shouldn't have to worry about, like basic image loading with caching and resizing. And that's just still images, never mind when you get into video de/compression.
Hopefully this is something the Android team is working on as they shift more effort toward Kotlin and Jetpack but I haven't had enough recent hands-on experience to know if this is better now.
For Vulkan and real time audio they expect you to checkout GitHub repos and compile from scratch, instead of having the tooling as part of the NDK.
Likewise after 10 years they still expect everyone to manually write JNI bindings, instead of providing another productive way for language interop.
I find image manipulation works pretty well, though I've only been doing Android dev for 2 years so maybe it's improved. Or I just haven't done anything 'fun' yet...
In retrospect, it would have been easier to just rewrite the whole thing in Android Java.
Basically, how little Google cares for game related development workflows on Android.
It just took them 10 years to acknowledge this, go figure.
https://android-developers.googleblog.com/2019/12/android-ga...
Can you elaborate on this? It just sounds like you have unnecessary complexity.
Once you realize this it's somewhat liberating. You focus on the bug/feature and not the method. One time I was trying to solve a particularly nasty layout-at-runtime problem and just realized I could write my own ViewGroup and lay it all out myself, pixel by pixel, faster than fighting RelativeLayout or whatever. And that code is more stable than something where I import some library that's not going to be maintained.
Unit tests are still valuable in a mobile environment.
Most good apps are simple. Simplicity is not easy.
Some aspects of mobile development will become far easier over time (memory management on iOS) while some will remain in a baffling stasis (refactoring tools in Xcode). It’s impossible to predict which category an aspect belongs to ahead of time.
There are times to embrace the approach taken by a platform, and times to distance yourself from it.
Mobile as a platform will crush all before it and transform society, while most contemporary technological hopes will remain geek toys.
The remembering self can really help out the experiencing self; you can never learn too much about the past, present, and future of mobile programming.
Work = looks and feels native, good performance, good widget collection, development that doesn't fight the platform, and all those available not 10 years after the platform was introduced.
Ditto async and observer and livedata type stuff. Never move data between things any way other than async. MVVM and all that, with caching repositories and stuff.
Architecture changes fast enough that you have to be careful not to waste time and effort supporting some ancient version and NIH writing your own implementations of stuff that's newly added in current versions. Yet if you try to ship using cool alpha quality features, that's a whole different headache. For extra fun you can end up with both problems at the same time in different parts of the app.
I regret that all of my friends and family have iPhones.
Also, I wish I realized that Google Play is giving you a lot of stats and data about your apps (store) performance these days, which in most cases can help pinpoint a issue with your reach/growth.
I also regret everything about Objective C ;)
To be clear, I do think Xamarin remains an interesting idea, but it's absolutely not the first thing I'd reach for when starting a x-platform mobile project.
What would you go with now?
• Interface builder(especially Storyboards) is inferior to using UIKit straight from code
• Coordinator pattern, which lets you split logic and view controllers. https://www.hackingwithswift.com/articles/71/how-to-use-the-...
Move actual work off thread whenever possible, but never try to integrate off threat memory access by hand using synchronized and friends, just enqueue your final result plumbing on the main looper.
Be paranoid about multithreading in the right places, particularly when you hand a callback to some black box. A callback that checks the thread it's running on to enqueue itself on main if necessary might become a familiar pattern. You might start to hate all callback methods that don't return void.
My decision to use NSThread for worker threads wasn't optimal either, but there weren't many async options in 2009 (Remember ASIHTTPRequest?)
One can always build a hybrid app from a pwa...
Learning iOS dev with reference counting as a memory management system was really painful. My programming skill wasn't up to speed yet to "just" learn a new language. I only knew some university Java at the time. And while I did write impressive projects with it, I wasn't strong enough in an algorithmic sense.
Learning a framework and learning memory management, and kind of needing to deal with pointers but not really proved to be too much.
When ARC was introduced it was a breeze.
Now, when I read this whole comment, nowadays I'd think: this is such nonsense. Memory management should not be a barrier to learn iOS dev. But when you're in that weird space of that you kind of know how to program (5000+ lines code) but you really need to get into it, and it doesn't feel natural yet. Then, yea, it does matter a lot.
A few years later I learned C and had no issues learning pointers or memory management. To be fair, I didn't need to use any frameworks with C.
It has been a nightmare of keeping up with the majors, just to be able to enter their carefully curated arena.
Nowadays when I build an App, I do Linux/Mac/Windows first, and the iOS/Android release, next. Fortunately there is a vast industry out there for toolkits and frameworks for solving The Platform Problem™ which has been shoved down our throats by a ravenous corporate culture which is hell-bent on ensuring that they own the computing platforms of the future.
Everything is relative of course, but can you back up your claim with some numbers?
Where do you live? What salaries and compensation packages are you seeing?
Well, ok, I guess it's not that grim. Still, it's a pretty crappy job.
Surprised me seeing Scala in there, thought it was basically dead now. My last experience with seeing it in a codebase and using (or trying to use) SBT, I was kind of hoping it was.