A recurring theme in just about all discussions revolving around the comparison of programming languages – apart from using the wrong tool for the job, adamantly pushing a language objectively/demonstrably inferior at x out of blind loyalty, bashing on languages you’ve never used or studied simply because you’ve seen firsthand how well received such comments can be, and worse – is acting off of stale information that no longer necessarily holds true.
At NeoSmart Technologies, we don’t just have one dog in the race; our software is developed in a multitude of languages, ranging from C/C++ to both desktop/web C#/ASP.NET, rust, [JS|TypeScript]/HTML/[LESS|CSS], (ba)sh scripting, and more.1 So it’s always interesting to observe these discussions (sometimes up close and personal and sometimes disinterestedly from afar) and observe what arguments remain standing once the dust has settled and the troops have gone home for the day.
Since we live in an imperfect world where we often have to trade ease-of-use for simplicity and abstractions for performance, while dealing with computer systems and standards you’ll often run into tasks that seem like they should be really obvious and simple only to later discover that in reality they lead down a rabbit hole. Such is the case anytime a developer comes into contact with the individual bits of a binary blob – and that can happen even when you least expect it.
The premise is simple: given a database powered by, for example, the extremely popular MySQL or SQLite RDBMS engines that do not offer “native” representation of UUIDs or GUIDs, database designers and systems programmers have a choice to make: do you store a GUID as a plaintext (
TEXT) and take the performance, memory, and storage hit that comes with it, or do you take off the gloves and dig out the
BLOB column type in your DDL?
Ask your favorite typophile about the difference between Arial and Helvetica, and you’re sure to regret it… unless you have a latent appreciation for the differences between font faces, the attention given to kerning and hinting, and more. But ask them what’s the difference between Tahoma and Verdana, and you might just be surprised by the ensuing silence. Yet, these are two of the most popular online fonts, and have aged significantly well considering they share corporate roots with Comic Sans and Arial.1 If any fonts ever deserved scrutiny and attention, it’s these two.
Here are two lines of text, one in each of the two fonts in question:
The sandy text editor is an open source project from the team over at suckless.org, which make painfully minimal1 alternatives for popular tools and applications for unix-ish platforms.
But perhaps the tense being used here is wrong. For quite some time, sandy, suckless’ minimal vi(m) replacement, has been unavailable. The git repository is offline; the root cgit instance returning the following “No repositories found” message:
At NeoSmart Technologies, we’re huge fans of the new Windows Subsystem for Linux,1 and have spent a lot of time trying to make the transition between the native Win32 subsystem and the Linux/WSL subsystem as seamless as possible.
For those of you that haven’t already seen it, we recommend reading our previous article Meet $, your new best friend for WSL for an introduction to WSL and
$, our nifty helper utility that lets you directly run Linux commands in your Windows workflow. In brief, we developed
$ (also known – though less affectionately – as
RunInBash) to make it possible to run Linux utilities directly from within a Windows workflow, complete with arguments,
stderr redirection, and more.
We may not know for sure what it’s going to look like or what it will cost, but we do know that the new iPhone 8 – Apple’s 10 year iPhone anniversary edition – is on its way and it’ll be running iOS 11. And unlike the iPhone 8, iOS 11 has been available now for some time for beta testing and software development. There are a lot of changes – some good, some bad1 – but there are two new features that are especially important to be aware of given that they could – literally – save your life.
HTTPS is the future and the future is (finally) here. Secure HTTP requests that provide end-to-end encryption between the client making the request and the server providing it with the requested content is finally making some headway, with almost a third of the top one million sites on the internet serving content over SSL:1
But what this chart doesn’t show is an important subsection of HTTP traffic that is unfortunately infamous for a general lack of security: IoT. The “internet of things,” as it is called, is famous for fiascoes that have allowed hackers to break into the privacy of homes, spying on consumers via internet-enabled nanny cams, gaining access to so-called “smart locks” to break into houses, obtaining sensitive information, and exposing private content and data thanks to insecurely designed consumer products and services that live on the local network.
If you haven’t heard of
tac, it’s a pretty nifty command-line utility that ships with the GNU utils and it’s used to print a file backwards, line-by-line. It’s especially useful when analyzing things like log files, and judicious use of
tac can speed up commands considerably.
Take the example of a 30GiB webserver access log and you want to see the last request to a certain resource or that triggered a particular HTTP status code. You could run the following to get the last such request… which would take quite awhile on anything larger than a few hundred MiB:
> egrep "GET /path/to/resource " access.log | tail -n1
Or you could be smart about it and use
tac instead, and not even have time to blink before the result comes back:
> tac access.log | egrep "GET /path/to/resource " | head -n1
If you’re still stuck on .NET 2.0, 3.0, or 3.5 for any reason and don’t have access to the
.CopyTo method for
System.IO.Stream objects, the
Stream.CopyTo extension method, available as a small NuGet package will make manually allocating buffers and other boilerplate associated with copying a buffer from one stream to another a thing of the past.