Anyone can learn to program if you or someone else forces yourself, but they won't if it's not something that they enjoy doing or see a big return on, or their mind just doesn't work that way. We tend to like doing things that we feel like we can be good at, and most people are not naturally inclined to have the potential to be good at programming.
However, don't be discouraged! If you're interested in programming, work at it, you'll get better, and you can still be better at programming than the vast majority of people in the world, and probably the vast majority of other programmers. Most people simply aren't motivated to work hard enough.
Having appeared in various shapes and sizes since Android 4.4; the amorphous blob that defined Google's emoji appearance since 2013 is being retired. In its place: a redesign of every emoji in Android, coming as part of Android "O" which was announced at Google I/O 2017.
Even though this brings the platforms closer together, I’m actually really sad to see them go.
The blob (gumdrop-shaped?) emoji were one of the not-so-many things about which I thought that Android had nailed down in comparison to iOS. My opinion was probably swayed by the Material podcast of which I was a pretty avid listener until about a year ago.
Even though some people have used iOS so much that they considered the round, not-quite-following-the-spec emoji the norm. Actually, it’s not “some people” – it’s probably the majority of smartphone users in the circles I spend my time in. Despite that, my love for blobs has and will remain strong and I’ll be extremely sad about their departure.1
But nonetheless, I have to say that the new emoji are not quite too bad.2 It could have gone worse (as it did previously).
(Also, let me insert this Vinesauce reference: the V-mouth has propagated even to emoji! Multiple times.)
There's a bit more love for the cute blobs over at The Verge. ↩︎
Taking a look at Google's mysterious third operating system.
This looks gorgeous.
About the reason of this OS’s existence, I quote Ars:
Unlike Android and Chrome OS, Fuchsia is not based on Linux—it uses a new, Google-developed microkernel called "Magenta." With Fuchsia, Google would not only be dumping the Linux kernel, but also the GPL: the OS is licensed under a mix of BSD 3 clause, MIT, and Apache 2.0. Dumping Linux might come as a bit of a shock, but the Android ecosystem seems to have no desire to keep up with upstream Linux releases. Even the Google Pixel is still stuck on Linux Kernel 3.18, which was first released at the end of 2014.
Another reason might be that Android has too much Java throughout it, and since the Oracle fiasco Google is striving for the removal of Java from Android as much as possible. This new OS makes sense in that they try to not use Java and instead use their home-grown Dart language which struggled and failed to be adopted as an alternative to JavaScript so fell back to a transpiled language.
And with a new OS Google is able to also clean-room how they make their apps. Dart looks pretty damn interesting as does the SDK. I’m certainly eager to see this project succeed.
Still, I’d hope that the customizability of Android would remain if not a priority, at least a possibility.
New PC runs Windows 10 S. Pre-orders start now, available on June 15.
Well well well, look who we have here!
So Microsoft just released this new laptop. Having quite a few things in common both with previous Surface products and borrowing elements from Apple’s lineup, this might be one of the most interesting things Microsoft have done this year.
However, there’s one small problem. Windows 10 S seems that it’s trying to tackle the low end of computers, just like Chrome OS. But then this Laptop is a contradiction – I doubt that $999 even comes close to “low-end”.
In any case, there is an option to upgrade directly to Windows 10 Pro for $50, which enables you to use all the things that you would expect (including running Win32 .exes), therefore making this a fine productivity machine… if you feel fine with a single USB-A port (i.e. no USB-C). The other specs look mighty fine.
This looks more like a threat to Apple and their lower-end MacBook line (essentially, MacBook and MacBook Air). We’ll see where this goes. I personally like it, but the thought of being essentially forced to use Windows does not sit well within me.
(Aside: I can’t find anything mentioning the unlockability of the bootloader, which makes me doubt it is possible, especially since the external booting kbase article does not mention the Laptop anywhere. If it is, this makes for a great portable PC replacement, if I can put Linux on it.)
So right now I have a device that is tragically nearing its official end-of-life from Google, however they’re still making the O Developer Preview available for that device. I guess now you’re sticking to your promises, huh?
Anyway, a highly interesting feature as of now is probably Notification Snoozing. This is something I’ve been missing for apps that don’t support reminders per se and just provide dumb notification services (or their snoozing controls suck – looking at you, Wunderlist).
Another, albeit currently less interesting feature is Notification Categories. I can’t really see an use for this just yet, but perhaps I’m just not in the right mindset yet.
However, the most interesting one right now is the picture-in-picture mode. Telegram has supported an emulation of this for a while now, but native support would be really nice. I actually use PiP on my Mac quite a lot, and I miss it on the rest of my devices every so often.
Notification badges sound nice as well, even though nothing supports them yet.
Anyway, I’m excited! I won’t be leaving Lineage just for O DP, but I’ll still be waiting until there’s a Lineage build (or I get a new phone, which is way less likely than the former).
ShuHaRi is a japanese martial arts concept that describes the stages of learning to mastery that can easily be applied to learning design.
So I was digging through my “read later” queue (2 years strong!) and found this masterpiece. It’s quite short and definitely worth reading.
Also some additional information about ShuHaRi can be found on Wikipedia.
Honestly, in the world of software engineering, there are not enough people who care enough about design, at least they are not the ones who get to make software. That is the reason why so much of non-public software looks horrible and is never really improved. Sometimes programmers have no escape and must create an interface – such cases often also have pretty bad results.
Therefore it has been my goal to improve my design skills at least to be good enough to make software that doesn’t suck when it’s used. So I’ve been following the ShuHaRi technique.
守破離 or ShuHaRi is a japanese martial arts concept that describes the stages of learning to mastery. Although it normally only applied to martial arts, the concept can easily be used in learning any skill.
Therefore I encourage you to read this short piece and perhaps also consider ShuHaRi next time you want to improve any of your skills.
Mozilla has acquired Pocket for an undisclosed sum. The nine-year-old company, which makes tools for saving articles and videos to view them later, is Mozilla’s first acquisition.
Okay, now that’s something I wasn’t expecting today.
So I know that Pocket and Mozilla share some history – Pocket started out as a Firefox extension, and then not that long ago there was some brouhaha about Firefox having a Pocket read-it-later button built in (which it actually still is, just checked). So buying Pocket isn’t all that surprising, actually, but I wasn’t quite sure that Mozilla was in the position to acquire anything at this point.
But as for the sale, I’ve got to agree with Stephen Hackett:
This follows Instapaper’s acquisition by Pinterest last year. It seems that read-it-later services just aren’t stand-alone businesses.
From having used some services for the past couple of years, I’ve made a conclusion that there are (or rather, were) three major read it later services: Readability, Instapaper and Pocket. And none of these three are standalone businesses anymore: Readability closed down last year, Instapaper’s been acquired 1 and now, Pocket has been acquired too. This indeed seems like a downward trend for these kinds of services, but well, at least Instapaper's now free! Right, guys?
I wish them all the best, and not only because I actually do use their service and have a way too many articles saved there right now, but also because their product seems genuinely good from what I've dabbled with it.
Aside: The Verge article couldn’t go out without throwing a burn in Mozilla’s direction:
And unlike Mozilla’s existing mobile products, people seem to enjoy using it [Pocket].
Also an interesting tidbit from the Mozilla post on the same topic:
[...] and [Pocket] will become part of the Mozilla open source project.
Wonder what that means?
Technically it was never really independent post-Marco, but I don't care. ↩︎
After a long day of fighting with programming tools, I popped on Twitter to see that the Nokia event I thought was on tomorrow actually happened today. Apparently a couple of phones were announced, and they're not really what I was expecting.
Nokia is going against the flow, just like OnePlus did a few years back. All of their phones try to pack moderate-to-fairly-good specs in a pretty reasonably priced package. You aren't exactly getting Galaxy S-line specs for this, but it looks pretty damn good for the price point.
I didn't just mention OnePlus in passing. Actually these new phones fill out a niche in which OnePlus has also dipped a toe with the X, which has been sold on and off for quite a while. 1 Unfortunately, OnePlus X didn't sell well enough2 for them to continue making them, and so the niche is empty once again.
There are many people who should upgrade to a better phone than their current one (most likely a feature phone), but also don't want to spend just too much money on their new phone. OnePlus X was sort of expensive for this category, yet it seemed to work fine.
But let's get back to Nokia. The brand new Nokia 3, 5 and 6 3 (priced at €139, €189 and €229 respectively) seem to hit just the right sweet spot of not too shabby specs4 balanced with an affordable price.
Of course, I can't finish this post without mentioning the resurrected 3310. 5 It's actually also pretty great for a feature phone, and at €49 not too expensive as well.
The new lineup seems to be just perfect for the European market, especially for the people who need (or should need) a better-than-nothing smartphone that "just works" and isn't weighed down by things like UI skins and subpar specs. I really hope this time Nokia swim not sink, because that would certainly be better not only for them, but for other folks as well.
Now let's talk about drawbacks! There's always drawbacks to be found.
This time it's the Micro USB port on all of these phones. Still not that bad, but takes away a bit. I thought that USB-C was the future.
The Nokia 3 runs upon a Mediatek chipset, which is not really a thing that I would endorse, however for the price point it seems reasonable. That seems to help save about €40-50, so I guess others won't mind.
The fingerprint sensor is integrated into the home button. That's also not anything of importance, however after using one next to the camera on the back, it's incredibly convenient. But I guess it's possible to live with one on the front if you try hard enough.
The 3 and 5 also have only a mere 2 GB of RAM. Having used a Nexus 5X with the same amount, it's not the worst, however there's often times I would wish for more. I guess the price might justify that.
The resolution on the 3 and 5 is pretty bad (720p clocking in at about 290 and 280 ppi, respectively), but again, you get what you pay for. The bigger one is at 1080p, which is quite alright for that price point though. 6
But that's about it for me. Looking forward to more info!
It's off now, not much of a surprise there. Actually, so is everything else -- right now one can only buy the 3T. ↩︎
[citation needed] ↩︎
As an aside, the preview pictures for some of these phones (where you can pick the color) seem to be really compressed. Wonder what's up with that. ↩︎
Also they got the button order right (glaring at you, Samsung). ↩︎
I could write an entire other post about the design that's visible in these screenshots, which I should probably hold off until I at least watch some video of 3310 being used. But still, I can't figure it out -- are those Opera icons on the 4 and 7 positions on the menu? [Edit: According to Wikipedia, S30+ supports Opera Mini. I wasn't sure that Opera Mini still exists and what is it doing on a phone not even equipped with 3G, but oh whatever I guess.] Also I love that they call the screen glass a "window". ↩︎
Note that the specs don't mention the pixel density for the 3 and the 5 ;) ↩︎
There’s quite a bit to be excited about, so that's why there's exclamation points everywhere!
First of all, it’s technically begun already, and there are already some news about new phones being quite a bit too expensive shown off. However, this is just the tip of the iceberg, and there’s more stuff coming up, such as Nokia resurrecting the 3310 among announcements from LG, Motorola and Huawei about their new flagships.
The part about Nokia1 is especially important to me personally, since I’ve used multiple Nokia phones over the years (both feature phones and smartphones). It always felt that their devices are top notch, and there was a lot of care put in making them. Even though the death sentence of using Windows Phone came from above, the phones themselves felt like they were made by people who believed in what they worked for. Of course, not everybody shares this opinion, but I truly believe that. And so I’m quite excited to see what they’ve been working on.
There's other stuff to expect as well, so I'm definitely looking forward to catching up to MWC as soon as possible!
Returning to the BlackBerry KeyOne. BlackBerry is still experiencing the Nokia effect (e.g. the iPhone taking away their market share and them not being able to fight back). Pretty much every one of their phones since the Storm has been more or less a flop, and their market share has plummeted hard. However, apparently it's been enough that they can make this new phone, the cost of which shows that they've learned little.
I have no idea who would buy this, apart from people who require a physical QWERTY keyboard and have expendable income.2 But I doubt that this is a viable strategy for keeping up their market share.
I have a weird fascination with old technology (I loved Symbian in its time, and I still am quite nostalgic for it), and BlackBerry's old Java-based OS is also of interest to me. It would be a shame if they went out of business.
Technically it's not Nokia themselves, but from what I can tell they're the same people who were behind Nokia once upon a time. ↩︎
I must admit I’ve caught myself guilty of this occasionally as well. For example, there already exist a couple of Telegram’s API wrappers for Node.js, however I’ve written my own each time I tried to finally get that tgfr shipping. I’m still stuck at the last rewrite (0.11 hype!), and I agree that I have my own way of doing an interface to an API.
But that’s reinventing the wheel. We don’t need any more of that, there’s already plenty in open-source.
Anyway that article’s great. Take it and think about it next time you do a side project.
The march for HTTPS isn’t slowing down any time soon, and that’s a good thing.
Let me tell you – nowadays there’s fewer reasons to avoid using HTTPS than ever. But there are still a couple of hurdles to overcome, and some of the progress seems incredibly slow.
Speaking of the linked browser behaviour change in particular, it will initially hurt the user (some pages are still mixed content and do not care enough to secure all of it properly, or they’re just too big to do that in a reasonable timeframe), however the complaints will either force the site owners to implement security or just tell (mostly corporate) users to GTFO and get back to IE9 or something.1
I do my part – all of the stuff I serve is sent exclusively over HTTPS.2 It's not really been any trouble, however that might be in part because I now have a very well developed workflow for integrating Nginx, Cloudflare and Let's Encrypt. However the good people over at EFF have been working on Certbot and making it more user friendly, so I doubt that the workflow would be anyone's biggest problem right now. It's the server-side support. I can afford the luxury of managing my own VPS, so all the liability to ensure the functioning of HTTPS falls on me and makes me get my ass off the ground and work on it, so I've done that. Others don't have that much luck. But all I can do is rant.
People, it's time to switch to a more secure internet. Or HTTP/2. Either's good.3
Did you know that there are still sites out there that claim to only work in Netscape Navigator 3.0? I've met a couple. ↩︎
There exists a single exception, however it's intentional (Lattelecom-Free users rejoice!) ↩︎
For those of you not in the know: HTTP/2 de facto requires TLS, so an insecure option isn't really a thing. ↩︎
Okay, so this started as a Google+ post (sorry, limited) which was intended to be a status update but turned out to be a mini-rant-slash-excitement-expression. So here I come to rewrite it as a proper blog post.
So of course, people write apps! I am currently dipping my foot slightly - working on a project that has been floating around in my head for quite some time now - and I can certainly see why people who have moved to native app development (e.g. Marco Arment) seem to really enjoy it. The increased verbosity pays off with you having so much more control and speed. There are frameworks for building bigger apps as well, although one can get along without really using any of them2.
So far I’ve gotten about 2 activities deep, and the app is generally not that big, but it seems that apps are quite hot right now, even though they’ve been cooling down for the past year or two. We have surpassed the app boom, now only the high quality ones remain and the -ware withers away.
But the Web is still dismissed by many, even though it continues to move forward (as in, replicate more and more of the app functionality with JS as much as possible). There are both pros and cons to both of these approaches, but from my experience native apps are actually nicer and usually fit in smoother than web apps3. So yeah, I’ll be moving over as well. Maybe.
We were able to get our app running fairly quickly, but the performance — specifically on touch events was not at an acceptable level even on higher end devices. (source - Discord)
↩︎
The only exception I’ll note though is something that helps dealing with HTTP(S) requests. The plain way seems a bit nightmare-ish, so I just use Volley instead. It seems nice and I don’t have to write everything from the ground up. ↩︎
Or wrappers for web apps. DESMOS, I’m looking at you. ↩︎
That's actually not just an emoji problem, but a problem with Android in general. Although it would be nice to have a mechanism for decoupled emoji updates just like there now is one for system apps and the Chromium web view.
So just now, following the theme of trying new technologies and seeing how they work, instead of blindly choosing Git I thought about picking a different VCS for a new project of mine.
So I stumbled upon this post. It’s quite long, however it is worth a read.
I’m kind of sad for Bazaar, even though I’ve never used it seriously (I’ve dabbled around long before I had any reason to). From this post it certainly seems superior, however choosing it now would be not quite wise, since it doesn’t seem to be alive enough. Perhaps people would call this state “stable”, but Git is currently both more performant and promising in the future. So I’ll be sticking to Git for this one.
So I should probably write this down so I don't forget it. Maybe someone else will benefit from this as well.
If you want to do server-sent events in Hapi, it's actually possible and not that difficult, but it's not as intuitive because apparently nobody likes server-sent events.
So this is literally what it says. You obtain a stream in some way. If you will manage the writing to the stream yourself (which you probably will), you can do this:
const Stream = require('stream') function createStream() { let stream = new Stream.PassThrough() setTimeout(() => { stream.write('data: Hello there!\n\n', 'utf-8') }, 1000) setTimeout(() => { stream.write('data: Here\'s more data!\n\n', 'utf-8') }, 3000) return stream }
Of course this is a bit dumbed down, but that's the simplest way to do it. Streams just seem like the right tool for the job, even though they don't seem to be designed to be used in JS directly.
I am not 100% sure why this part is here, but I think there was something weird with disconnections not closing the stream and leaking memory, essentially. Please do drop me a line if this is not correct.
I feel like this is pretty self-explanatory, but I want to go over the Transfer-Encoding: identity bit. By default Hapi sends streams using the chunked encoding, which is what you likely need when you're sending streams not generated by your code. However that means that bytes go over the wire like this:
14 data: thing 1 14 data: thing 2
Before the actual data the server sends how many characters will the data take up. This is better for dealing with binary data and such, but apparently browsers don't like the chunked encoding when dealing with EventSource. They expect a flat, simple stream like this:
data: thing 1 data: thing 2
My limited testing revealed that the content length prefix makes the browser not accept such data as a valid event source. 1
Content-Encoding: identity ensures that the data won't be compressed with gzip or whatever your browser requests. That also seems to break the stream.
Although the standard specifies that identity shouldn't be explicitly used as a Content-Encoding value, this is the only way to make Hapi send streams as-is without chunking.
Anyway, that's how I did event streams for a previous project of mine. Do let me know if something's not working or has changed since I last checked.
Edit 2016-12-28
After a bit of using this solution, I've found a problem -- Hapi (gracefully) closes stream responses if there is no data written for 2 minutes. Therefore you should implement some sort of a keepalive mechanism if you want to use a single EventStream (to prevent data loss, most likely).
The code examples were also updated slightly since browsers like when both Transfer-Encoding and Content-Encoding are set to identity. Using gzipping will not really work with event streams.
Of course, please note that this might have changed in recent Hapi versions, or the browsers might have changed their behaviour. As I said, my testing was limited. ↩︎
And also quite a few Google apps get better treatment from their iOS teams (Hangouts) and some are not even available for Android (Gboard).
Huh! Well that's not true anymore! Google Keyboard has become Gboard now!
Now it includes a proper emoji lookup (😍), integrated Google search, GIF support and also improves on multi-language support (now up to three languages using the same alphabet can be enabled, similar to SwiftKey).
Finally Android is receiving some of the long lost Google love! No Assistant though. 1
Not that I really miss it, for the same reason I don't use Allo. It oversteps my boundaries a bit IMHO. ↩︎
