You would be surprised at how little of the code in a CI product, like CircleCI, deals with git. On the other hand, there is a lot of code required to integrate with the VCS - authn, authz, webhooks, commit-status, etc.
1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
2. It doesn't actually replace a USB drive. Most people I know e-mail files to themselves or host them somewhere online to be able to perform presentations, but they still carry a USB drive in case there are connectivity problems. This does not solve the connectivity issue.
3. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the service, is it reasonable to expect to make money off of this?
Basically grids is a 2D layout system, while flexbox is a 1D constraint system that results in stuff happening on the second dimension. They're complementary and it would be foolish to use one when the other is needed.
No CSS Grid Layout is far, far more powerful and versatile than tables ever were. Certain significant classes of layout problems that were either a major pain or even outright impossible with current CSS tools are about to become fairly straightforward.
Flex is only built and meant for handling linier layout, either up and down or left right, and ot does so well with good flexibility and options and developer experience. Or at least compared to the other possible options. It was never intended for making grid layouts, which people are often trying to make it do, because all the other options are so lacking.
> "Slightly cleaned-up Java with a bit of syntax sugar"
This is not an accurate description of Kotlin.
Kotlin has many features that make it better than Java. Most importantly, it is null-safe. In addition to that it makes it simple to enforce data-immutability, which is very difficult in Java.
> Kotlin has many features that make it better than Java. Most importantly, it is null-safe. In addition to that it makes it simple to enforce data-immutability, which is very difficult in Java.
Kotlin does have nullability handling yes, but it's a very limited special-case feature - it's a language-level builtin rather than something you can use in your own libraries. E.g. if you want to have an error message in the failure case rather than just null (i.e. some kind of Result type), you can't reuse any of the null-safety functionality (whereas in Scala or Ceylon you can write the same methods to work with either optional/nullable or result-like types).
Data immutability isn't at all difficult in Java. It's tedious (sprinkling "final" everywhere), but not hard.
> it's a language-level builtin rather than something you can use in your own libraries
The only people who still think that a library approach is superior to a compiler approach are Scala users.
I'll clarify this for you: if it's a library construct, it can be ignored. And as a matter of fact, there is nothing in Scala forcing you to use `Option`. You can completely ignore it and enjoy your time diagnosing NullPointerExceptions everywhere.
When a feature is enforced by the compiler, such as Kotlin and Ceylon, you don't get any easy way out: you have to think about null cases or you will not be able to compile your code. Period.
You're conflating two different issues. Yes, Scala allows null and yes, this is unfortunate, though it raises the question of whether there's any better way to do Java interop (you can either assume all Java calls are non-null unless checked, assume all Java calls are nullable and force checking, or trust annotations; all these approaches suck in their own way). It can be mitigated with WartRemover.
But the right way to represent absence - whether you call it null or option or something else - is clearly with a normal type that follows the normal rules of the language, not a special language-builtin type with special language-builtin rules. Some light syntactic sugar for commonly-used types makes sense (like Ceylon's "?"), but what it desugars to should always be something you could write a normal library type for. Indeed if your language doesn't let you implement the constructs you need for this kind of type in a custom type in a library, that should be a red flag that your language isn't expressive enough for general-purpose use.
> (you can either assume all Java calls are non-null unless checked, assume all Java calls are nullable and force checking, or trust annotations; all these approaches suck in their own way)
Agreed, which is why Kotlin has explored all of these options and ending up implementing neither.
Calls to mutate state, such as changing the name field, should be rare. I don't see the value in adding syntactic sugar to make it easier to mutate state.
He means you'd call `increment(25)` to say you've got 25 more, or `employee.suspend()` instead of `employee.setAccess(SUSPENDED); employee.setPay(0); employee.setBenefits(NONE);`
a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.
> a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.
Yeah I want to say that for us developers, "rare" is not something that we can code, without some serious sophistication.
More likely we code "if" and it is either "yes" or no".
To capture "rare", we need some serious tools - statistics, analytics etc etc. That is way beyond the regular developer toolset.
I have red/colour blindness and I find that the contrast between the red and green borders on cells is very low (they look quite similar to me).
It doesn’t stop my playing - it just slows me down.
It might be something you address is you find you have many players with colour blindness.