evanspa

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]

Looks pretty cool. I also recently developed an app to track strength training workouts. I also used React/Redux for the web app. The iOS app is native though (supports offline mode and offers Watch app) and Android is in-progress.

https://www.rikerapp.com

Good luck with your app!

Really fun to read. I grew up in Schenectady, played Schenectady youth hockey and later got a job with GE in downtown Schenectady. It was there I started using Java (v1.0.2) building rich client apps using AWT (Swing didn't exist yet). One app was for building a pricing engine for steam turbines. Good memories.

Developer here. Thanks for checking out my new app. 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.

Will be happy to answer any questions.

Blatant self-promotion. I just finished initial development of a web app [1] for tracking your reps, and have just submitted an iOS / Watch app to the App Store (currently in review).

[1] https://www.rikerapp.com

Really though, it's better to think that Lisp has no syntax, and that really you're writing your code directly in the parse tree that other languages compile-to. The parens are simply to define the boundaries of the trees.

And besides, with proper indentation, it becomes easy to read and easier on the eyes.

So I worked exclusively in the statically typed (and imperative / OO) world for the first 10 years of my professional career. Several years ago I decided to learn functional programming. I started with Scheme and moved to Clojure. I really enjoy Clojure; it's a real joy coding in it using Emacs with paredit (or smartparens).

I wrote a REST API using Clojure; the code also has to interact with a Postgres database. This is for a side project, but it's not a trivial code base. I definitely miss Java/Eclipse style refactoring (right-click, rename, and EVERYTHING is properly updated). Can't do that in Clojure. Also, I find that I have to write more unit tests with Clojure in order to make up for the fact the compiler can't help me. Not that I wouldn't write tests in Java; but I find I have to write more in Clojure to keep the codebase manageable.

So again, for me, I use unit testing to make up for the fact I don't have the compiler helping me as much.

I've been a lot of programming in both lately (Clojure and Objective-C), and did a ton of Java earlier in my career, and I find I like both. The biggest pain point for me in Clojure is the inability to easily refactor.

To overcome the limitation that the machine can't help as much when using a dynamic language, I've found that writing good unit tests with solid coverage gets me pretty far, and shortens the feedback loop when I break something.

But yeah, I sure do miss the right-click and 'rename' feature from Eclipse and Xcode when writing Clojure.

Not in my experience for what it's worth. Every software dev position I've held in the last 10 or so years offered 4 weeks.

Keep. I have a iPhone 5S and with the original markup, I'm unable to read the site in portrait.

Clients of a hypermedia REST API are supposed to have a priori knowledge of the link relations (the "rel" attribute). The fact the rel in this example looks like a URI is sometimes used as a convention (i.e., if the API supports it, a client may do a GET against the rel value, and get back a human-readable description of the purpose of the rel).

In the human readable description of the "/linksrels/slot/book" link relation, information should be given about what generally can be done with such links (like if GET or POST is supported, etc). This allows you to build your client applications. The value of the actual link (the 'uri' attribute) should be completely opaque to the client.

Pretty ironic you've been posting here for 4 years to a site built with a language that's not useful.

Based on your username, I'm not surprised you like the time-traveling angle.

Or, they could do it lazily. I.e., only force the 2FA at the time of money send / receive.

gadders was being sarcastic.

I watched for a couple minutes, and started to feel a little nausea. Anyone else? Not sure how this bodes for the general concept of helmet-attached GoPros.

(the Checkers are my home team! - cool seeing them in this vid)

Yup. Good catch :)

"If it's possible to keep the super intelligent AI in a virtual environment, but it can't detect that it's virtual."

They did this in a Star Trek TNG episode ("Ship in a Bottle"). Data accidentally endows a holodeck character with super-intelligence. The way the crew eventually defeated him was to trick him into thinking he had left the holodeck and was able to live normally in the outside world; but it was really just another virtual environment.

* It gives me hope. It's the only activity (for me) that may one day lead me to fully control my destiny (i.e., side project -> lifestyle startup)

* I can be god-like. When working on a side project, I get to make ALL the decisions.

* It's rewarding. Being able to take an idea born purely from my thoughts, and make it into something real, is inherently rewarding. Although I guess this applies to any creative endeavor, with coding it's cheap (all I need is a computer) and the feedback loop is short.

This. Like most folks here, I like learning new things. I learned Ant a long time ago, and then Maven (to GP's point, learning Maven was NOT trivial). When I started through the Gradle docs and realized that it's a DSL written in Groovy, I had to open a new tab in my browser and start learning Groovy. Now I'm thinking to myself: "Great. In order to really grok Android Studio, I need to learn Gradle. To grok Gradle, I need to learn Groovy." As I mentioned in a previous comment, with all there is in this life to learn, I just can't bring myself to learn Gradle when I already know 2 other Java build tools :)

No, I wouldn't say I'm doing anything specific. No on NDK. It's simply that Eclipse/Maven serve me well (I'm even able to create/run Android unit tests with the android-maven-plugin). In short, so far my entire workflow is well-served by Eclipse/Maven.

I'd concede that Studio/Gradle is the future, and that Gradle is more powerful than Maven; my "issues" are purely emotional :) With all that there is to learn and explore in this world, I don't want to have to spend time on another Java build tool when I already know 2 good ones (Ant and Maven).

I'm in 2 minds regarding Studio. On the one hand, I'm a whiz at Eclipse and Maven, and because time is so precious, I have no motivation to learn Gradle, and so I use the excellent android-maven-plugin[1]. (I'm also dependent when using Eclipse on the Emacs+ plugin for Emacs key bindings) When learning a new language / platform, I'm fine with learning its "standard" build tool, but with Android dev, I wish I could use Maven. I just can't emotionally bring myself to have to spend brain energy on yet another build tool chain for Java dev (I'm already juggling "build tool chain" knowledge for iOS dev and Clojure dev, just to name a couple).

On the other hand, I want to be using the best and latest tools, and stay up to date with what the broader Android dev community is doing.

Would love to hear from others with similar feelings...

[1] https://code.google.com/p/maven-android-plugin/

To build on what you're saying, one could argue that functional programming also is a way to model the world; that is, if you're model of the world is that of a series of snapshots of instants, as opposed to mutable stateful objects. Abelson from the SICP lectures argues this in this lecture:

http://ocw.mit.edu/courses/electrical-engineering-and-comput...

I'm with you. My favorite language is Blub.

I would think you'd have a different username :)

I was mainly Java dev for 10+ years or so; I was a whiz at Eclipse. Then, one day, I forced myself to learn a Clojure. It just so happened the ecosystem mainly leveraged Emacs. And so, I forced myself to learn Emacs. It took a while - the key bindings, reading up on how to do various things, discovering great packages, learning enough Emacs Lisp to be dangerous.

It was very rewarding, and I use Emacs everyday now. Today, I can't imagine not using it.

When you provision a card to Apple Pay by taking a photo of your card or entering the info manually, what happens next is that the iPhone makes a call to the card network (Visa/MC/Amex) to verify the card data (the card network will also make a call to the issuing bank of the card for a validity check), and if all is well, the network will return the same information that is effectively provisioned to physical ICC chips that you see in newer credit/debit cards. These parameters are stored in the iPhone 6's secure element, and allow the iPhone to perform full EMV transactions.

One difference between these parameters and those provisioned to a physical ICC on a new debit/credit card, is that the card number (PAN) is not used; instead a payment token is used (it looks like a PAN - it has the same number of digits, etc). This allows Apple Pay transactions to run on the same infrastructure as chip+pin/signature transactions.

Yes - that's right.

When you provision a card to Apple Pay by taking a photo of your card or entering the info manually, what happens next is that the iPhone makes a call to the card network (Visa/MC/Amex) to verify the card data (the card network will also make a call to the issuing bank of the card for a validity check), and if all is well, the network will return the same information that is effectively provisioned to physical ICC chips that you see in newer credit/debit cards. These parameters are stored in the iPhone 6's secure element, and allow the iPhone to perform full EMV transactions (as apposed to simply just EMV Legacy MSD transactions).

I started my Lisp journey seeking to learn Clojure too. I starting out with The Little Schemer[1]. I chose Scheme so that I could first wrap my head around the basic Lisp syntax, along with the recursive and functional thinking. To keep things as simple as possible, I did 95% of the exercises using a composition notebook and pencil[2]. This kept the incidental complexity to a minimum.

Later, I moved on to the Clojure books. Working through the Little Schemer was invaluable (and its bibliography is excellent too).

[1] http://www.amazon.com/Little-Schemer-Daniel-P-Friedman/dp/02...

[2] https://github.com/evanspa/TheLittleSchemer/blob/master/sche...