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.
> 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.
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...)
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.
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.
> 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.
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.
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.