kikibobo69
Joined 17 years ago
Karma
571
Submissions
70
Member since
Dec 5
Recent submissions
Comment · 7 months ago
Comment · 11 years ago
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
Comment · 11 years ago
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
Comment · 11 years ago
PUT should be idempotent, though.
Comment · 11 years ago
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.
Comment · 12 years ago
We're working on a very low-tech version of this at Zalando, here: https://github.com/zalando/aws-minion
Comment · 12 years ago
Care to recommend some alternatives?
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.