evanspa

Another reason not to return a 404 in that case is that chances there will be monitor tooling in place that will treat a 404 as an "error" that will show up in your alerting, but would not be ideal; it will just be noise.

"vicious" Think you meant to say "vacuous"

In my 40s. I feel that way too sometimes. My advice: try new things! I just started motorcycling; signed up for MSF course, got a used bike and it’s awesome. I play beer league hockey and that one night a week playing and being with the boys is precious (and theuropeutic…in a house with only daughters and wife lol). Snowboard in the winter…got my kids into skiing…golf in summer…LeetCode for fun to keep my mind/coding sharp. You get the idea. My day job (Android coding) is kinda mundane and is really just for the paycheck…and so my personal philosophy of life is to keep trying new things, diverse things, not being afraid of new things, and just going for it. I’m never bored and I don’t sweat things like “legacy” and whatnot. Enjoy life!

I do! I did the 2019 AoC in Clojure and really enjoyed it. I plan on getting to the 2020 and 2021 ones at some point.

I'm in my 40s doing the leetcode grind, but weird thing is, I'm actually ENJOYING it. I get a little high when I solve a problem, and I feel good about re-learning / re-discovering data structures and algorithms that I just don't use on a day-to-day basis. I paid for the premium version and enjoy reading the solutions and maybe learning a new trick or algorithm technique or whatnot. And who knows, maybe something that I learn when grinding on some leetcode problem will actually be useful in my day job? Thinking about it, if I ever do land a MAANG job, I don't think I'll stop doing leetcode problems. Sure, I won't go crazy with it like I'm cramming for mid-terms or something, but I'll still hack on them for the pure joy of problem solving, for the sake of problem solving.

I guess where I'm going with this is, maybe change your thinking about leetcode? Don't think of it as a necessary evil in order to land a high paying job that you dread doing each night; look at it as a fun little hobby, with the nice side-effect that you're keeping your data structure knowledge, algorithms and general problem solving skills sharp.

Great article, love Clojure. Was trying to figure out what Nanit does. Might want to consider putting a link to the Nanit homepage on your engineering page. When just typed in nanit.com and saw the baby monitor tech, I thought maybe I went to the wrong place, until I saw the logos matched. Anyway, good read, but please put a link to your home page on your engineering site, or, put a 1 liner in the opening of your blog giving context to what your company does.

> Note that CORS preflight requests are not made for GET HEAD POST requests with default headers.

I really wish the author included an explanation for this. What are "default headers"? What special header(s) needs to be on the request in order for a preflight request to be made?

I think it's just called the "broken stick" rule. Specifically, if you break your stick, you HAVE to drop it on the ice immediately and be done with it. If you even skate back to the bench holding it, you can get called for a penalty.

I don't think it's fair to mention the police confrontations without all the facts / context. Simply put, based on the reporting by The Washington Post, the situation is not so clear-cut:

https://www.washingtonpost.com/news/monkey-cage/wp/2018/08/2...

You should check out my strength tracking app, Riker:

https://itunes.apple.com/us/app/riker/id1196920730?mt=8

https://play.google.com/store/apps/details?id=com.rikerapp.r...

Why do you feel it is "the natural tendency" to make minorities feel less welcome? My natural tendency -- and anecdotally, pretty much everyone I know -- is to treat people well regardless of their race; to treat people the way you'd want to be treated.

I delivered a session at JavaOne (2001?) on Ant (I was a whiz at it). Then, I had to learn Maven as it gained traction. I'm currently doing Android development, but I'm a little embarrassed to say that I don't really grok Gradle the way I do with Ant and Maven. I don't have anything against Gradle. I just don't want to spend another minute of my life learning another Java build tool. So, I stick to the Gradle defaults when creating a new project in Android Studio, and rely on SO and whatnot whenever I need to customize. Haven't been burned yet.

In my beer hockey league (Charlotte), goalies have to pay the league fees too. And it's up to the player-coach to find a sub if the primary goalie can't make the game. Our league is relatively "formal" in that we all have to be registered with USA Hockey; our games have real refs, time keeper, etc. But I've been in other leagues, less formal, where goalies skate for free.

Ice hockey also has the +/- metric, and as a defenseman that doesn't get a lot of goals and assists, I'm glad it's there.

Developer here. Thanks for checking out my app, Riker. In case anyone is curious, the iOS app is native, written in Obj-C. The Riker web app is written using React and Redux. The REST API is written in Clojure and the backend is Postgres.

Although there is also a fully functional web version of Riker, the app is preferred since it supports offline mode, provides Watch App and integrates with Apple's Health app.

Shouldn't there be a connection between the top-right red circle and green circle in that very first graph?

Agreed - it would be really great to have automatic recording of reps like we have for steps, but as you pointed out, you would need "smart equipment" and "smart free weights," which are either very far off from happening, or won't happen, which is why I built Riker. Being able to record reps from the Apple Watch is the most friction-less for me so far.

Developer here. Thanks for checking out my app, Riker. In case anyone is curious, the iOS app is native, written in Obj-C. The Riker web app is written using React and Redux. The REST API is written in Clojure and the backend is Postgres.

Although there is also a fully functional web version of Riker, the app is preferred since it supports offline mode, provides Watch App and integrates with Apple's Health app.

Will be happy to answer any questions.

App Store link: https://itunes.apple.com/us/app/riker/id1196920730?mt=8 Web link: https://www.rikerapp.com

Sorry if it's already mentioned, but I found it frustrating that I could not get to the winnie homepage (http://www.winnie.com) from the blog. Even the "Home" nav link at the top of the blog just points to the blog's homepage.

You are right. The way I solved for this scenario is that when a record is first created on the device, a GUID is created for it (and stored using another column of course). When POSTing new records to the server for syncing, the server will check the GUID and see if the record already exists in its database, and if so, can ignore it (so the duplicate isn't written).

But yes, you're right overall - full offline mode w/syncing, etc is a big pain :)

In my strength-tracking iOS app Riker, I use SQLite directly (not CoreData) as my local data store, and support full offline-mode. The backend is Postgres.

In the app, for each relation (e.g., a "workout set"), I have 2 tables: a master and a scratchpad. When a user saves a set, a row is written to the scratchpad table. When the user syncs it with the server, a row is written to the master table and deleted from the scratchpad table. When the user wants to edit the record, I first copy it down from the master table to the scratchpad table. All local editing impacts the scratchpad row. When the user wants to sync, only if a 200 response is returned will I copy-up the scratchpad row to the master row. If the set was edited on another device and the local copy is out-of-sync, the server would have responded with a 409 (http conflict code), and the body would contain the server copy, which is then written to the master table. The user can then figure how they want to merge the scratchpad row and the master row.

Anyway...trying to do all this with CoreData would have been a pain, so I use SQLite directly, and works great.

Or to summarize, I handle offline mode, syncing and conflict detection using "updated_at" timestamp columns along with logic in my REST API to returned appropriate HTTP status codes, interpret "if-unmodified-since" headers, etc.

https://itunes.apple.com/us/app/riker/id1196920730?mt=8

Riker on Android is currently in-progress...

Java has always allowed for class members using the "static" keyword.

The GoF book predates the public release of Java. The code samples in GoF are in C++ and Smalltalk.

Correct me if I'm wrong, but Java 8 does allow functions to be passed around. E.g., if a function takes as input a Runnable, I can pass a no arg lambda expression as input.

Developer here. Thanks for checking out my app, Riker. In case anyone is curious, the iOS app is native, written in Obj-C. The Riker web app is written using React and Redux. The REST API is written in Clojure and the backend is Postgres.

Although there is also a fully functional web version of Riker, the app is preferred since it supports offline mode, provides Watch App and integrates with Apple's Health app.

Will be happy to answer any questions.

App Store link: https://itunes.apple.com/us/app/riker/id1196920730?mt=8

Web link: https://www.rikerapp.com

Thanks. Honestly, I didn't even know that Garmin offered an SDK to build apps. Will have to build a Riker app for the Garmin's too :)

Because I'm still working on the Android / Android Wear version, I haven't done a ton of marketing yet. I did have business cards printed up with the URL, logo and some screenshots, and have been handing them out to random people :) For monetization, I offer a subscription that costs $11.49/year; with that you get an account enabling your data to be stored on my servers and thus accessible to all your devices, including the web. Without an account, the app itself is free (with all features included), but the data is only available on your device (unless you manually export/import to other devices, which you can using the app).

Yes - that's what I'm currently working on.

Thanks for the feedback. Yeah - it's definitely a bootstrap design. The website is functional, but it's the mobile app that is best to use (has Apple Watch integration and offline mode).

I couldn't find a workout app that I liked. The ones I tried just didn't fit the flow-of-use I wanted. I just wanted something to track my weight lifting, and wanted it to be super simple. So, scratched the itch with Riker.

https://www.rikerapp.com

I built an app for it to track my weight lifting (not aware of a Fitbit or Garmin that does that).

https://www.rikerapp.com

Thanks for checking it out - really appreciate the feedback. Some responses:

"the web version costs money after 90 days but the app is free. Why the differences?"

Because the web version stores your data on my server (and thus making it syncable to all your devices) - and so for that capability (and to cover my server operational costs), it's a paid feature. But if just using the iOS app, all of your data is by default stored locally on the device (I'm using Sqlite for that), and so that's free (since I don't incur any operational costs for that).

"it seems that I cannot add any other exercises apart from the ones provided, would be nice to be able to quickly log what I wanna do."

I thought about that in the beginning, and ultimately decided against it for simplicity; and would instead go the route of incrementally adding more and more exercises myself to the app. But will perhaps re-think this.

"the records list view on mobile is a bit squished (i.e. I find it difficult to horizontally scroll)"

Will look into this. I'm currently using an OSS library for the records display, and so I'll see if there are params I can tweak.

"no support for super-sets: I do a lot of circuit training and I somehow managed to add this feature to Ewolo using a rest parameter. I'm still not sure what the best way to model this data would be without making it cumbersome."

I also struggle with how to model supersets - more so from a UX standpoint. You're totally right - you'd think a rep tracker would be easy, but as you get into it, there's quite a bit of complexity that emerges. I think I have a good way to handle supersets, but that will have to be for a future release...currently trying to get the Android app (and Gear app) done.

Thanks again for the comments.

[edit - typos etc]