CookWithMe

I believe (hope) I haven't been the most distracted parent - I banned all news apps and facebook, twitter etc. from my smartphone long ago.

Three weeks ago I broke my iPhones screen on a Friday, and we did go on a family trip over the weekend, so I had to go without a smartphone. It was great, I felt more connected to my 2-year old son, but also to my wife.

After that experience, I've purchased a dumbphone. Yes, I really do miss some utility apps, but overall I'd say it has improved my life.

I'm working since 3 years at a growing startup that has been hiring Scala Engineers at least every half year since I started.

In the last ~18 months, the amount of CVs we're getting has been constantly increasing. Part of that is probably that our startups hiring matures, but it's also the kind of CV that is changing.

I'd say that 3 years ago, there was an 80% chance that the applicant was highly self-motivated to learn Scala in their freetime, and tried/did introduce it at his/her current workplace. Today, there is an 80% chance that the applicant either "had to" learn it in their current workplace, or learned Scala when switching jobs. (Don't get me wrong, they're still motivated, and they took the chance when it was there!)

So there is a switch from the Early Adopters to the Early Majority (where the Early Majority now has worked 1 or 2 years with Scala at their current job, and is confident enough to look for a new one).

One driving force was definitely Spark, but there are a lot of Enterprise apps, unrelated to ML (usually with higher traffic requirements). The sort that would have most likely been done with Java or C# 5 years ago. It seems a lot of Enterprises introduce Scala when they try to break up their (Java) monolith into microservices.

So it seems that Scala has been carving out it's place in backend/microservices with scalability requirements, and is eating part of Javas cake there.

Their marketing claim of "Full Self-Driving Hardware" is evil-genius - it's very similar to the Halting problem[0] - Turing proofed that we can not develop an algorithm that can predict whether any program will eventually halt.

It's very similar with this marketing claim. We can never show that the hardware is not capable of being self-driving. Maybe, someone, at some point in the future, could pull it off. Even if the rest of the industry uses Lidar, beefier chips etc., it is not proof that it can not be done with that hardware. Tesla can keep playing that game, until virtually no one owns the current generation of cars anymore.

[0] https://en.wikipedia.org/wiki/Halting_problem

The main concern with this approach is that the event store is no longer immutable

I think what happens when you delete all events of a (deleted) aggregate root (such as a customer who requested to be forgotten) can be interpreted more charitable, in a way that the event store can still be called immutable.

If you look at a functional programming language, you can not force a data structure to be removed from memory. However, that obviously doesn't mean that your program consumes infinite amount of memory. If a data structure is not referenced anymore, it'll be removed from memory (by the GC). Your program itself didn't mutate the state of the data structure, so from that point of view everything is still mutable.

Now, let's apply the same principle to an event store: A deleted aggregate root (the to-be-forgotten customer) should have been removed from all projections (as required per GDPR). If you replay the events, it shouldn't matter to the final state of a read projection whether it processed the events belonging to this aggregate root, or not.

Therefore, one could interpret that removing the events of a deleted aggregate root in a GC-like fashion leaves the event store immutable, in the sense that my program(s) can't mutate the state (themselves), and their output doesn't change.

Volvo is also manufacturing a car with a pedestrian airbag, the V40: https://support.volvocars.com/uk/cars/Pages/owners-manual.as...

Both Volvo and Uber could have opted to use this car instead. Even choosing a SUV is question-worthy, as they're known to be more dangerous for pedestrians due to higher bumper heights: https://en.wikipedia.org/wiki/Criticism_of_sport_utility_veh...

IMO there is at least some negligence on their part for not choosing a car that is more likely to protect pedestrians.

Not if you get ulcerative colitis, cancer, or similar.

Or if you get a baby and want parental leave.

Or if you want to send your kids to university.

I wrote some RAML recently and found it very good for creating a machine-readable representation of an API. We also wanted to make it human-readable and use it as our API reference (with the API console). I found it to be mostly good, but had some trouble when explaining larger concepts that span several requests. Also, it's harder to point to the "important" parts of the API if it's sufficiently large than it was with our "freeform" reference.

I haven't looked into Swagger deeply, but RAML seems better at re-usability. Swagger seems to have way more traction though, and also more tools.

The Soviet Gas Pipeline explosion - if the whole CIA story is true at all - should not be labelled a bug... The code allegedly did exactly what it's creator intended ;-)

Looks really cool. I was first thinking it saves the JSON with the new Postgres JSON support, but saving it as relational data is even more impressive!

I'd say if the OPTIONS would return a JSON Schema (+ RAML/Swagger) instead of the json-fied DDL, it would be even more awesome. With a bit of code generation this would be super-quick to integrate in the frontend then.

What is so ugly about it? Swift tries to be somewhat close to the usual C-syntax (it's supposed to be the successor of Obj-C, after all).

For someone used to C-syntax, I guess the main deviation is that the return type is in the back and that there's a func keyword. As for the operaters, there is the addition of generics (what is wrong about <> ?), -> to describe signature of a function (a very sensible choice IMO) and ? for Optionals (again, fine for me).

I don't really see how a statically typed language can substantially improve this, but I'd be happy if someone can proof me wrong :-)

I would walk away. Actually, consider yourself lucky that they've shown their true face so early on and you can get out now :-)

When considering hiring a lawyer etc., also take a look at opportunity cost: Even in the best case scenario, will you get more money out of it then if you freelance for a similar amount of time? Probably not...

(Also, learning from the Winklevoss twins, it seems preferable to sue a company when it is actually successful, because they got way more to loose at that point then now. Although I strongly doubt that they'll be successful...)

you look better each day than the day before

Again, this is only true if you are unfit. I have been doing sports regularly for the last decade and my body is in good shape. My doc says I'm healthy. Loosing more weight would make me underweight...

Yes, I could become more fit, but training for endurance won't change my body visibly.

And everyday, as you think back to when you could only do X amount of Y

I have come back super-fit from two-week vacations were I spend nearly everyday mountainbiking or hiking. Back in the city, I can't spend 10-12 hours outdoors everyday. At the very best, I'm maintaining that fitness level, but most likely it is getting worse.

When I was younger, I had the attitude you're prescribing: My fitness became worse, and it was emotionally affecting me because I was searching for a feeling of success. Now I'm aware that my fitness level changes seasonally, reaching bottom at the end of the winter and peaking in the summer. I'm fine with it and I enjoy doing sports just for the sake of it.

I'm 100% for doing some sports, and sticking with it while doing a startup.

I'm 100% AGAINST doing it for a "guaranteed win" :-)

First of all, there may be a direct relationship between effort and win when you're an unfit twenty-something, but if you get an injury - or just if your body gets older - you may be struggling to get back to the level you've been at before.

But, even more importantly, if you do sports with a "I have to win"-attitude, you'll start comparing yourself to others, and you'll always find someone who is better than you. Just don't start to be competitive. You're doing the sports for fun. Learn to enjoy sports for it's own sake, and you may be able to take that attitude towards other things in life.

(I've got a failed startup behind me, and one of the things that kept me sane was regularly going bouldering. Pro-Tip: Get a yearly membership as a birthday or xmas present from your parents or so. Even if you're in serious financial troubles, your membership will be paid for. Huge relief!)

I have never used a gift card at starbucks before, but that bill [0] doesn't make any sense to me.

He says he has two cards: One has $15, one has $5.

Card 3203 is billed $14.68 and card 6075 is billed $2.02.

The remaining balance on card 3203 is $0, card 6075 has $5.70 remaining.

If card 3203 had $15 and card 6075 had $5 before he used them, the remaining balance should have been $0.32 and $2.98, respectively...

That's really me guessing, but it could be the $5 was just an example to explain the concept and in fact he used smaller values (e.g. $0.05) to be able to trigger the bug more often without generating too much cash... but he should have explained the bill somehow.

[0] http://sakurity.com/img/sbcheck.jpg

You're right, there isn't anything wrong with the six stages per se.

The root cause is really that (a) they're forcing a stateful model onto the web and (b) that the way they're keeping/restoring the state is expensive.

The lifecycle stages are more a sympton of that. Most web framework these days go with a stateless approach. One notable exception is the lift framework for scala (although I'm not sure if it's really active anymore). I have only looked very briefly at it, but it seemed to give the programmer more explicit control of the state...

A simplified example to demonstrate the problem: Imagine a B2B app with a medium-sized table, where each row contains multiple objects. A HTTP request is send for performing an action on one object.

In a stateless approach, the programmer decides which objects he needs to serve the request. In JSF, the framework restores the complete state as seen in the previous request, and will also setup a lot of other magic (event handlers, validators, what not) - no matter whether it is actually needed to serve the request or not.

So one ends up with stages in the lifecycle that waste a lot of time, but one really hasn't much control over.

Well, a lot of Java web apps ARE slow as hell, but one can't really blame Java-the-language (or the JVM) for it.

Two examples from my experience:

JSF is doing lots of "magic" trying to keep state. It isn't exactly quick to render a simple hello world page, but if you mess up the state on a somewhat complex page, JSF spends ages in it's six (yes, six!) lifecycle stages [0].

Hibernate is probably the worst offender. Well, the interface is somewhat nice: you don't have to care about loading objects from the database, Hibernate will load them for you. One object, one request at a time. Looking at the hundreds of generated SQL requests it's quite easy to figure out how you would write better SQL... but you don't write the SQL, Hibernate does :)

The lesson IMO is: If you're writing everything from scratch, language performance is important. If you're using frameworks, the performance of the whole stack is way more important and one should probably compare benchmarks - or even real-world applications that are similar to ones use case - of the whole stack.

[0] http://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html

Simply "not using Rails" anymore however is, well, not that simple!

After the OP has described why he likes Rails ("good toolset", "Ruby gems cover everything"), I would've really liked to know why OP wants to switch away from Rails.

so what's around that has a chance of replacing Rails? Go!

Again, the OP gives no reason why he switched to Go instead of looking at another web framework for Ruby, and also not why he chose the particular Go frameworks to replace Rails.

That's what would've really interested me, after the introduction I didn't quite see a Go-tutorial coming...

Very high on my reading list is "Leading Snowflakes"... but since I didn't read it yet, take it with a grain of salt.

Since you mention that you're working in a distributed team, I've read Remote by 37 signals. It was mostly advertising on why one should work remote, but it has some bits on how they manage their remote workers which you may find useful. However, I overall felt the book was rather light on content/substance as someone who has read about and tried remote working before.

Good Luck! :-)

When experimenting with standing (well, also walking) desks I found that the height of the table is less important than the height of the monitor, and that using a plain laptop, as shown in the pictures, isn't any good if you want to work for longer (>30 min) periods. Constantly looking down isn't a natural position, and it strains the neck.

The cheap option is to raise your laptop and use an external keyboard/mouse, or use an external monitor. Or both :)

I've used this for an app I've build for fun (to check out Swift).

It ranks bad for both Yoga and Meditation, yet one can't use the app for anything else. I could, theoretically, remove these keywords, but what would I replace them with? I have no idea, and your tool doesn't help me.

I'd say it is more valuable to rank for a strongly-related keyword anywhere than to rank high for a weakly-related keyword. I.e. if my Yoga and Meditation app ranked #1 for Airplane, it would be completely useless :-)

Otherwise, I enjoyed using the tool. Nice flow through the process and good visualisations in the end.

Because he went through an accelerator. He'll be told for months that the demo day and the pitch will be super-duper important, because investors.

I attended a different accelerator than him (but also corporate and in Berlin), and the idea that bootstrapping may be viable, or even that waiting for another 6 to 12 months when one has real feedback from the market, was never brought up. This is especially sad, because the situation in Berlin is basically inverted to the one in SV: Living costs are cheap, raising (seed) money is hard.

Our Demo Day... afaik no startup got an investment because they met an investor there :-) Afaik, some proceeded to later (>12 months) raise money, one did have success with crowd-funding. But we all wasted a serious amount of time training our pitch...

In a couple of years, there will be no need to own a car for most people. Lots of car-manufacturers have already started to build out the infrastructure for "cars on demand" (e.g. drive now, car2go). In Berlin, there is already always a car within a 5 min walk from my apartment.

Once driverless cars are here, people will just request a car Uber-style and it'll be wherever they are within a minute in any metro area.

It'll be cheaper to not own a car, and it'll be a lot less hassle than owning one (as it probably is today if you're taking Uber instead of having a car).

One will of course use mobile devices inside the car, as we do now as passengers... and Apple makes enough money with that.

Yep, been travelling through SE-Asia for the last 3 months. Loads of scooters here and they're parked anywhere on the street or sidewalks. Even if you'd theoretically get a power outlet from an apartment onto the street, there would be no way of controlling who uses it (=probably everybody).

Actually, that wouldn't even work in the apartment building I live in (in Berlin, Germany). Some people park their scooters in the courtyard... a public power outlet would probably be used for anything imagineable before a scooter would even get a half charge.

IMO: If you are finishing up a side project iOS / Android app, don't bother with a website. Just get it out of the door! Traffic doesn't drive itself to the website. If you drive traffic somewhere, you may as well drive it directly to the App Store.

There is no reason a quickly cobbled together website that has the same screenshots your App Store listing has will convert any better than the App Store.

Plus, the iTunes web page is pretty good at SEO and will probably turn up before your own page for relevant keywords.

In fact, the time you save by not building a Landing Page, you can invest into:

a) Writing a great description of your app. Also includes relevant keywords for your niche, you may want to use a keyword-research tool. https://searchman.com/ seems to be the best free tool atm(?).

b) Make sure your screenshots not only show meaningful data, but also clearly communicate why/what your app is useful for, e.g. how a problem is solved. Explainer texts can make it A LOT easier to communicate that. Shameless plug of a side project of myself: http://www.screenscott.com

c) When the app is live, make sure it gets downloaded and reviewed. Tip: Ask friends / family to download the app and give you feedback. If you get criticism -> Great, you'll know what to do next. If you get positive feedback -> Great, they've already written the review! Now you just need to ask them to post it in the App Store :-)

Yep, you are right.

I looked deeper into the Scala implementation of Option [1] to see how Scala achieves that, and whether I can port their implementation to Swift.

Long story short: Scala has a bottom type [2], Swift does not, therefore the Scala-implementation can not be ported to Swift.

A bit more detail: In Scala, Some and None are not enum-Values (as in Swift), but there is an abstract class called Option which Some and None inherit from. Option is a generic class. None is not generic anymore (this alone isn't possible in Swift!), but is an Option[Nothing]. Nothing is the bottom type: it can be returned for any Option[U], because Nothing "inherits" from all classes, and therefore also from U.

OK, that was still pretty short - if anyone is interested in a longer write-up including code, please let me know and I'll write a blog post :-)

[1] https://github.com/scala/scala/blob/838ff2c2f256d1c114a406ff...

[2] http://en.wikipedia.org/wiki/Bottom_type

Nice article, well done!

Minor question/comment regarding the implementation of Result.map: Why do you create a new Result in the error case? Result is immutable (or am I missing something specific to Swift here?), so the old and new Result are the same and stay that way.

I'm not familiar with the internals of Swift, but e.g. in Scala, there is only one "None". If you call map or flatMap on it, the same None will always be returned.

Although I agree with the conclusion (have several small projects in addition to a "big" one), I think the intro is off.

It takes ten-thousand hours to master your field, so the story goes, except that programming is too broad of a field.

If you've put in ten-thousand hours into the field of programming, you'll not need to put in another ten-thousand if you switch from, say, a vector-drawing tool to a music composition software. Yeah, you might miss some stuff like everything related to audio - but picking up the concepts and one or two related APIs should be two or three orders of magnitude quicker than "I'm learning to program".

Learning new concepts and APIs is meta-skill, and one will become better at it the more different concepts and APIs one has used.

You'll also need domain knowledge, of course. Again, working with domain experts and users is a meta-skill that you may want to train (or you may depend on someone in your team to do most of that for you, e.g. a Product Owner).

So, if someone has "mastered programming", she should be able to be dropped into an unknown domain and have the skill to identify and pick up the parts she is missing in a fraction of the time it took to "master programming". Mastery of a skill means the switching costs between domains is significantly reduced, but not zero. Same is true for a carpenter: Building a ship is different from building a house or a bridge, yet a master of carpentry will be able to pick up the skill of building a ship more quickly than, say, a master of programming would.

Most fields are too broad to know "everything" about, that is not specific about programming.

I personally use bitbucket for my repos, yet I would not want to loose access to github.

GitHub has become more than a DVCS: Loads of relevant Open Source projects are hosted there. If I want to contribute - or even browse issues - I need access to GitHub. Same goes for discovery.

Also, lot's of tutorials will provide their example project on GitHub. Plus, GitHub both hosts a fair amount of static pages of Open Source projects and individuals, plus some blogs/tutorials embed gists when the use code samples.

I didn't play too many 2-player dominion games, but I enjoyed the 3 or 4-player games more.

For both types, card sets with little interaction usually have one or two good strategies, and luck plays a large-ish role in whether you or your opponent(s) can execute the strategy faster.

Card sets with more interaction are IMO strategically more interesting with more than one opponent. Usually, everyone will focus on keeping the strongest player from winning, who in turn gains less from further weakening a single opponent already weaker than him. In 2-player games, the stronger player can just lash out at the only other opponent, which directly increases his chance of winning.

So the chance of turning a game around after half the time played is much slimmer in a 2-player game than in a 4-player game, from my experience.

Anyway, Dominion is a great game that packs a lot of strategical depth in a rather short playing time!

I had the same feeling when I did my first side project in Swift earlier this month. My main experience is with CoreData.

An example with 1:n relationships: CoreData returns and expects an (untyped) NSOrderedSet. Now I may either keep the NSOrderedSet, but have to cast each object I want to use - and my Swift code is just as bloated as Obj C would be:

  let obj = mySet[0] as MyClass

  let obj = mySet[0]

Or I create a typed Array from the NSOrderedSet, which is fine to work with in Swift - except that it is not managed by CoreData anymore. So I'd have to be careful to synchronize with CoreData manually, and it's not just saving that I have to watch out for, but also other operations like rollback etc.

Another example is NSNumber. NSNumber needs to be manually mapped to Int, while the other direction works automatically. That makes sense when it is unknown whether NSNumber is an Integer or a Floating Point Number, but in CoreData I have specified that it's an Integer 32... (Well, I think it was similar with Obj C, actually).

So, working with Swift in the Playground felt like a huge improvement over Obj C at first, but then working with some Cocoa APIs it started to feel ... more clunky again.

I think it was/is similar with Scala. If you can stay in the Scala libraries, awesome. It is a huge improvement over Java. But Scala won't automagically turn a terrible Java API in a great Scala API. Yes, you'll save a couple of semicolons and type declarations, but it's not that big of an improvement. Thankfully (in Scala), there are a lot of better frameworks or wrappers for existing frameworks by now. I guess Swift will have to go the same way...