Nodu is a minimalist personal development app that helps you stay focused on long-term goals, day by day. Every morning you decide what you will do and what you will not do by swiping away objectives and only keeping ones you want to focus on for the day. Throughout the day you can mark items as complete and check on what objectives remain.
I'm surprised to see Kotlin in your list. Google has stated they are increasingly moving Android development to a Kotlin-first ideology. New official libraries produced by Google for Android are designed with Kotlin chiefly in mind, so it may provide significant benefits to support, community, and documentation.
Considering the popularity of the Android platform and Google's control over it, I don't think it is a bad idea to develop an Android app in Kotlin. According to Google, their Maps, Home, Play, Drive, and Messages apps are all built in Kotlin, and my personal experience is that Android developers like and prefer Kotlin.
I found out about Arctype a while ago when I started writing for their blog about SQL, a topic I really enjoy. I'd recommend checking out their product if you spend a lot of time in SQL databases: it has tons of cool features, a nice flow & layout, and it might just be your thing.
Author here. I have sent/received 643,576 messages since 2009 which totaled 590MB. To my knowledge media is never stored in the SQL database (for iMessage).
While web browsers on iOS are unfortunately just re-skinned Safari, you actually are able to create/download totally custom keyboards. A while back I created a custom keyboard to translate what you type and help you learn a new language.
TerraStride is an established Portland startup making web and mobile mapping applications for outdoor enthusiasts. We're looking for an Android developer with experience developing and launching at least one high quality app. This Android app developer will work with our team of talented engineers to design, build, and improve our advanced mobile mapping application. A successful candidate should have a strong sense of product ownership and be comfortable working semi-autonomously as an engineer.
While I had a positive experience with the Uber app software-wise (app functioned seamlessly landing in Mumbai from U.S.A.), Uber as a service was not really comparable to what it is like in the U.S. and developed W. European countries. I got the sense that it was more of a strictly ride hailing / request service, not much accountability required from the driver. Often had > 3 drivers cancel after 10-15 minutes waiting before actually getting a ride. That being said, it was still a hugely valuable service to have in India as a foreigner.
I've gone back and forth on this in respect to database tables and ultimately prefer singular. If the table is named "profile", I think it's obvious that it can store more than 1 profile, since... well it's a table and has rows.
I was in Death Valley last weekend. Drove there from SF with Model Y, ended up renting an ICE car to explore the park, especially since we were staying 1.5 hours from the center of the park.
I saw several Teslas around the park, and I think it's doable if you only want to visit say 1 or 2 locations, but without a Supercharger in the middle of the park, you will be limited and won't have the flexibility to see everything.
The resort in the middle of the park has 4 J1772 chargers, which would help if you were staying in the park overnight, but we were simply doing day trips.
I interviewed at Discogs about 3 years ago (after discovering they were local to me in Portland, OR). Seemed like a great group of people working there!
Yeah, wasn't trying to say this was an example of graph. Maybe it is slightly outside what would be considered "standard" relational DB use case? My impression of recursive CTE's in RDBMS is that if you need speed or any more advanced graph-like features, you should move to an actual graph db. So far I haven't taken on any projects that warranted that, though it does interest me.
Either way my intention here was to simply provide an example of a real-world recursive CTE use case.
In the past I used recursive CTEs in Postgres to calculate the BOM of a product. Products consisted of "parts", and each "part" had a cost and could consist of any number of other "parts" (subassemblies).
This was for a homemade ERP resembling software.