(assuming the bug here is a description being assigned to a title)
getDescription simply needs to return a Description object while getTitle returns a Title object. Duh.
Only in the final rendering should it get turned into a string and there it should only accept a Title type for doing so.
Okay, I'm kind of joking, but this is seriously the solution if you really want to get down to it - primitive overuse is the problem, so wrap it in a type that makes it explicit. You need cheap and easy types to take full advantage of this sort of thing.
EDIT: And even with those reading code developed in such a way may go overboard at some point. I'm not sure as I haven't really seen it done to the fullest extent possible. Typically even when taking a fairly strong advantage of such a type system, unit tests and stuff are still used, but theoretically you could enforce their parameters entirely in the type system. Of course, that enforcement can also be incorrect, but it does make it clearer in many cases.
I can see your argument in some cases, but if you are accepting input, at some point you'll have to accept a string (or any primitive) and convert it to your custom type.
How does static typing ensure you're mapping the correct JSON input fields to your custom types?
> How does static typing ensure you're mapping the correct JSON input fields to your custom types?
Ideally you push it all the way out. Rather than JSON you use Thrift or similar where the messages are strongly typed.
But if you do use JSON, how much benefit does unit testing your JSON mapping really give you? The mapping in code is just a list of field:field pairs, the test is just the same thing, is there really any value in repeating it twice? I'd sooner rely on careful code review than a test.
Yeah, they talked about numbers of bugs fixed, but those surely seem to have impacted the user experience. My big worry is that if I were to consider deploying to such a service, that I would encounter similar bugs, but not have the political pull to get them fixed and simply have to perform hacky fixes around them myself.
I've switched everything I write to use runit because runit doesn't require any particular init system, you can easily integrate it with sysvinit, freebsd's RC, ubuntu's upstart, systemd, etc. It just runs on top and doesn't need to be the king and it's incredibly simple to write scripts for it. Completely removes the need to worry about this init mess.
The thing is though - their code is already written. Systemd is entirely unnecessary for 99% of people, probably everything except some of it's LXC features has clear and popular alternatives. LXC is the only thing making me eye systemd with interest, but I'll come back to it in a few years once all the weird stuff is worked out.
It's nice to hear that you have the choice of not running systemd.
All production ready Linux distros (RedHat (and by extension CentOS), SuSE and Debian) are all running systemd and as a systems administrator for a large company I _must_ adopt it, I don't have a choice.
If those major distros weren't switching though, you wouldn't have to, which is what my point was. The only reason you're adopting it is not for a practical benefit, just because the distros did.
I run devops though for a small business and we've avoided the issue entirely using runit for our software.
Are there any pickins for android phones with keyboards with even remotely modern hardware (I'd settle for anything with a 1080p screen probably)? Seems extremely limited, I was unable to find any viable options last I checked. I hate the candy bar form factor but it seems as though it really has won out unfortunately.
The problem is, a keyboard adds to the device cost quite a bit. And most people, despite saying they want a keyboard, are not willing to pay above and beyond for it. They want the same price point they're already at. So that means cutting costs elsewhere.
Blackberry's own Priv from late last year is the only modern choice. Reviews generally indicate that it was good, but not great. Had minor issues with heating up and having a clicky back I think. Was mostly stock Android aside from a few small tweaks.
I looked at it but both price and lack of root and bootloader unlocking are extremely prohibitive for me. The keyboard is really its only appealing feature.
I can get a device like a OnePlus 3 for about 60% of the price and it has better hardware to boot. In terms of storage, RAM and CPU it's more comparable to a OnePlus 2 which is about 40% of its price.
Keyboard is nice, but not double the price and lose features I rely upon like AdAway and XPrivacy kind of nice.
Agreed, those are among the reasons I haven't picked one up either. Not sure what price One Plus 3 is, but it's worth noting new Privs on Ebay generally fluctuate between 299 and 350 USD, which I'm guessing may be similar to OP3.
Looks promising. Doesn't seem to support subscriptions, though, which is the problem every unofficial YouTube app seems to have. Probably because logging in and accessing subscriptions requires the API, which has a ToS.
Yeah, the XBMC Youtube addon used to do subscriptions and the like, it was pretty nice, but I think it broke and the main developer abandoned it. Youtube-dl does support channels and resuming though so you could fairly easily just set up a cron job and use syncthing to get the videos onto your phone. No pretty GUI for that though.
I personally use an RSS Reader to handle my "subscriptions".
The YouTube-webpage also has an option to export your subscriptions to an OPML-file (which can then be imported into an RSS Reader): Log into your YouTube-account, then go to "Manage Subscriptions", and then at the bottom of that page, there's a button for it.
(This is how it worked a few months ago. I actually don't have a YouTube-account anymore, so I can't check if it still works like that.)
On Android, I personally use SpaRSS [0] with it, which does work quite well, but it being available on F-Droid was pretty much essential to me, so if you don't care about FLOSS, you might be able to find an RSS Reader which integrates even better with this setup...
By installing a custom ROM without also installing GApps. For example, I have a Nexus 6P running CopperheadOS, which doesn't include GApps (it, like CyanogenMod, supposedly supports it but makes it optional/separate from the OS itself).
There is also this app [1] (shameless plug, I wrote it) which uses youtube-dl to download videos off any supported sites. No real UI as it just parses the media URL (when a link is shared to it) and passes it off to the android download manager.
I threw it together (over a few hours) simply because I like watching stuff on youtube at 1.5x speed and the android app does not allow you to do it (whereas if you use VLC to play the downloaded video, you can increaseplayback speed)
It's also available on the play store [2] with youtube downloads disabled by default
I just tried NewPipe. However, after downloading a video, you can no longer play it directly in NewPipe (with NewPipe's ability to play in the background), only in an external player.
I'd love this kind of report with various things. I'm thinking phones would be extremely helpful too, how easy is it to unlock the bootloader on this phone? How hard is it to repair it? What proprietary blobs does it rely upon?
Of course, just doing this would be illegal on most proprietary operating systems.