kikibobo69

I'm training for a charity ride up Mont Ventoux this summer. I kept hitting the wall on long training rides despite knowing the theory, such as Jeukendrup's work on carbohydrate oxidation rates, dual-source fueling, and the rest of it. The problem wasn't knowledge. It was that I'd forget to eat when I was suffering.

FlöFuel is an iPhone + Apple Watch app. You enter the products you're carrying (specific gels, drink mix, salt tablets), and it calculates a fueling schedule based on ride duration and intensity. The watch taps your wrist when it's time to act.

Product-aware scheduling. Most apps say "consume 30g carbohydrate." This one knows your specific products, such as that your Maurten 160 has 40g carbs, that your SaltStick caps are 215mg sodium, and tells you "take a gel now" or "take a salt tab."

Open-ended rides. If you don't know how long you'll be out, it shows rates and coverage instead of totals: "1 gel every 25 min, your supply covers about 3 hours."

Temperature-adjusted targets. Pulls ambient temperature and adjusts hydration and sodium upward in heat.

Carbohydrate targets from the literature. 40–90g/h scaled to intensity, with a GI absorption cap. Not bodyweight-based.

Implementation. The allocation problem (distributing intake across multiple products with coupled carb, sodium, and hydration constraints) is a variant of the bounded knapsack problem. The core services are formally specified in Z and the key safety properties have Lean 4 proofs. Probably overkill, but I wanted to be confident the algorithm was correct before trusting it mid-ride on a mountain.

No account, no backend, no tracking. Everything stays on device.

Happy to discuss the algorithm or the WatchConnectivity implementation, which turned out to be the hardest part.

At Zalando we have an account per team, and have been releasing a bunch of tooling to help do this securely.[1] It's not completely easy (e.g., account creation at Amazon can not be automated), but the security aspects are really nice, and it lets us give teams more or less full access to just their account.

[1] https://stups.io

Zalando is hiring in Berlin, Dortmund, Erfurt, Mönchengladbach (Germany); Dublin (Ireland); and Helsinki (Finland).

Zalando has built an entire fashion ecommerce stack, and is now starting development work on a number of new tech initiatives around extending beyond being just an ecommerce website to being a platform for connecting people with fashion. There is a lot of high end engineering and product work, from programming warehouses to building Big Pipe to cutting edge data science to building entirely new customer facing products.

It's a great place to work and an incredible product vision.

Check it out: https://tech.zalando.com

PUT should be idempotent, though.

My former colleagues have been working on http://apidoc.me/ (https://github.com/gilt/apidoc). I really like this approach, which is basically:

1. specify the api in json 2. apidoc generates really nice api documentation 3. apidoc generates a single-file client for the service (currently ruby or scala) 4. apidoc generates a routes file for play2

It's scala-biased at the moment because that's their tech stack, but in practice an api-first approach seems to lead to higher quality APIs compared to just hacking something together and annotating it to extract docs. Also having a really nice client without a complicated compile-time dependency graph (on the JVM) feels like a sweet spot.

We're working on a very low-tech version of this at Zalando, here: https://github.com/zalando/aws-minion

Care to recommend some alternatives?

Why are these called promises and not futures?

The xml stuff is more the exception than the rule. They've moved away from that approach. Whether to keep it at all has been discussed quite a bit. It would be more fair to look at the newer code in the collection framework to paint what is considered "best practice" by the creators of Scala.

Same for me on Chrome + MacOS. I opened it in incognito mode and it worked.

Agreed, not sound reasoning, but here's a nice summary of the challenges of Clojure on Android: http://stackoverflow.com/questions/4651757/clojure-on-androi...

Bill Venners, owner of Artima, is a co-author of the Staircase book, and author of ScalaTest. He has embraced Scala more than most.

I used to agree, until I ran into a bunch of inline StringBuilder Java XML where no schema existed, and simply converting it to Scala at least ensured it was well-formed while we reverse-engineered a schema. I agree it's not something one should use much (well, maybe with Lift), but wow, is it ever useful when it's useful. I agree, doesn't hurt much; helps massively when you need it.

This post misses the key point about working for one of these big outsourcing companies: there is no technical career path. The only way to advance in a company like Wipro (the one I have the most experience with) is to become management. This leads to a very unhealthy dynamic, and I don't see how these companies can remain competitive over time. Without an equal investment in ensuring that they have some technical skills to bring to the table, they will never been much more than a cheap place to outsource your testing or running a complicated build environment. I'm amazed they can't see that.

The people who actually manage to write a few thousands lines of Scala (and end up happy), are great people to code with (or hire) in my experience.

It's easier to better engineer complicated things in simple ways when you are less encumbered by non-essential complexity. Once you surmount the learning curve, Scala brings a lot. If you can't or won't put enough in to make it, well, sure, it won't be for you. Personally I like solving problems that are hard enough to benefit from Scala's expressiveness. But I completely concede that for lots of people, there's just no reason not to keep on doing Java. Or Cobol for that matter.

C# isn't a realistic option for a lot of people with big investments in the JVM. It is clearly an interesting language, but, it's no F#.

Obviously there are no silver bullets that make software development easy. But after having written a handful of high performance, high availability systems in Scala, the benefits over the other alternatives on the JVM are so evident to me, it's easy for me to get frustrated that they aren't obvious to everyone. Of course we still have occasional bugs, and sometimes they are hard to diagnose. Just exactly like Java, and any other language you care to choose. Bugs are inevitable. But there are a couple of things that make Scala stand out, and I'm a bit surprised at how fickle the community is about this language. One day everybody loves it, the next day, everybody seems to hate it because it didn't make programming easy. Both are extreme; as engineers and scientists we should approach cautiously and methodically; doing so, in my view, makes a few truths unescapable:

1. Scala is far less code than any statically typed language on the JVM. Less code means fewer bugs.

2. The Scala collection framework is a tour de force. If you can't see that, you should keep looking. Seriously, it is quite simply amazing for anyone coming from Java -- there is nothing like it. Not since I first got a taste of STL have I enjoyed the hybrid sensation of aesthetic awe with the 120M volts of power. It is just so clean, so orthogonal, and such a pleasure to work with. It is hard to go back after you have gotten used to this thing.

3. Scalacheck takes testing to another level. When I take the care to properly use a tool like Scalacheck to cover what I'm working on, the number of bugs goes as low as I've seen on any platform, anywhere. I have live code which I am pretty damn sure doesn't have any bugs. The only code I've written in 20 years of doing this that doesn't have any "not critical enough to fix" bugs, is written in Scala. I cannot tell you how satisfied that makes me feel -- it's a long time since I considered that possible.

It is difficult to argue against the idea that there are too many ways to do things in Scala. There is more than one way to do a lot of things, and I personally find the right way for me to be fairly evident after writing a few thousand lines of code. As an engineer, I'm all for constraints to make my job easier. But at the same time, since writing code is a very indirect way to express ideas, it can be nice to have an expressive, fastidiously symmetric, means to do so. The symmetry in Scala is breathtaking ... the edge cases in Scala are an order of magnitude less bizarre than the edge cases in Java. After a few months of Scala, the pathological examples touted in these comments look completely obvious. They are doing a powerful thing. Learning to think in the language is required if you want to be fluent. And what I love about learning to think in Scala, is the extremely intelligent hand of its creator is evident everywhere.

One reason for not having return, has to do with symmetry, which Scala is full of.

For example, val x = if(foo) { a } else { b }

This is a lot nicer than the alternatives, and I suppose you could force people to write:

val x = if (foo) { return a } else { return b }

...why, why? It doesn't really add much. Once you get into the functional mindset, it becomes natural how this works, and the occasional place where you are forced to add a return statement becomes a place where there is almost certainly code smell. No returns is basically one of those constraints that helps guide you towards more functional code with fewer side effects.

Indeed, you are right...

I think the key thing is that there is no mechanism to be sure that messages you send to actors are immutable. There is a compiler plugin in development to help, though.

I'm sure I will regret this, but:

One guy at our school that went to Oxford -> One guy at our school WHO went to Oxford

All of the friends I have that went -> All of the friends I have WHO went

I came to complain about the poor precision -- thanks!

One nice trick with Option, is how you can replace null checks for common operations. For example, consider the difference between:

InputStream i = ...

if (i != null) { i.write(...) }

vs.

val i: Option[InputStream] = ..

i.map(_.write(...))

Simple, safe, works really well.

Seems he's deleted the repo now.

Java defines it in a very useful way. It's identical to an AtomicReference, but without any test&set semantics. Anything other than that seems pretty dangerous.

Personally I find the issue with volatile is that it's quite subtle unless you're looking at the declaration. I tend to use AtomicReference even if I don't need test&set, unless it's extremely performance critical, but it almost never is. The inner loop variables don't need to be volatile.

I noticed it does 64 bit only on Windows. Not a good sign for other platforms.

I guess I see "fits in 80" as a virtue. If it's pushed up against the right hand margin, I tend to refactor. Code that I can't make look nice in 80 cols, is very often code I don't like maintaining over time.

How is that nice? (Serious question...)

80 cols is nice for printing. Also vertical screen real estate is cheap; horizontal is a lot more expensive.

I've been using Scala for about a year now. Started writing some test using ScalaTest, ScalaCheck, and Specs, and really liked it. Then I solved some hard problems using Scala, with a lot less code, and a lot fewer bugs, than it seemed like we would have ended up with using Java. I'd say about 99% of our codebase is still Java, but the Scala bits are quite noteworthy both for leading to something nicer to maintain over time (mostly by need no maintenance, or very very little), and for solving a hard problem without an explosion of Java boilerplate. A more functional approach ends up being a bit easier to test. The collections framework is >awesome<. For us it has been a slow, grassroots thing, and I don't think we are going to see a big bang, but those of us who have taken the plunge have a very hard time going back to Java.

Which slide was THAT on?

I'm reacting to slides like: "individuals choose what they want to work on" which is all fine & well, except that sometimes, if we want to ship in time for Christmas, people might have to work on what they wouldn't naturally choose.