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
Have you ever wanted to quickly find out how long your system has been up and running for? Did you come back to a suspiciously empty desktop when you could have sworn you left some apps open and suspect your PC automatically installed some updates and rebooted while you were gone, but couldn’t be sure? Our latest application,
uptime, is the answer you’ve been looking for.
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.
Just a quick heads-up for all our readers: our recently released RunInBash utility – which makes mixing-and-matching PowerShell/Windows/CMD commands with WSL/Linux/Ubuntu commands under Windows 10 as easy as prefixing WSL commands with
$ to execute them from within a command prompt or PowerShell terminal – is now available under Chocolatey.
Continuing our promise to open source parts of our libraries and applications where possible, we’ve just released
PrettySize, a C# and .NET library for representing file sizes in a human-readable (pretty) format.
PrettySize is available for free (MIT-licensed) on GitHub and via NuGet for those that are interested, and forks, contributions, and pull-requests are actively encouraged.1
One of the best benefits of open-sourcing code is that it requires you to take a critical eye to what your code does and how it’s structured. Haphazard code interspersed throughout a dozen different files is cleaned up and re-organized in a way that can only bring benefits all around, from performance to ease-of-use, security, and future maintenance.
If you have any skin invested in the high-performance computing game, you’ve almost certainly heard of the likes of MMX and SSE, the original “extensions” to the x86 assembly instruction set that provided task-specific performance-optimized instructions that let developers take advantage of specific hardware extensions to quickly perform tasks that previously required extra steps in software to compute. If you haven’t, here’s a quick briefer.
The “basic” instructions supported by PCs are known as the “x86 assembly language” and is the lowest level of code available for writing software that runs on a “regular PC,” originally developed by Intel and adopted by other players in the CPU game (including AMD and the now-defunct Via CPUs). All PCs from the original Intel 8086 way back in 1978 to modern, multi-core behemoths support this language, and code written in or compiled for x86 can (in theory) run on any machine from 1978 onwards.
1Password and LastPass are probably the two best known names in the password storage business, both having been around from 2006 and 2008, respectively. Back in 2008, the internet was a very different place than it is today, especially when it comes to security. Since then, a lot has changed and the world has (hopefully) become a more security-conscious place – and security experts have come to a consensus on a lot of practices and approaches when it comes to encryption and the proper handling of sensitive data.
Both of these password managers are heavily vetted and constantly under scrutiny from security researchers, crackers, state security agencies, white hat hackers, and more with open bug bounty programs   (though some considerably more generous than others), and are probably “safe” choices for the average computer user.. to an extent.
One of the biggest improvements to C# and the .NET ecosystem in recent years has been the introduction of the
await programming paradigm and the improvements it brings to both performance (no need to create thousands of threads if they spend most of their time blocking on IO) and productivity (no need to muck around with synchronization primitives or marshal exceptions between threads). While it takes a bit of getting used to, once you’ve gone
await, you (literally) can’t go back.
We are proud to present the latest addition to our open source portfolio, the Unicode.net library! We’ve extracted a number of encoding- and emoji-related namespaces and functions from a few of our projects going back many years and split them off to create
Unicode.net: an open source library that can be used to aid in the safe processing and manipulation of (possibly) internationalized strings and non-ASCII characters (and then some).
Unicode.net is designed from the ground-up as a modern approach to text processing and text encoding, with only support for the most popular Unicode encodings: UTF-8, UTF-16, and UTF-32. Additionally,
Unicode.net is designed to complement .NET’s existing (albeit extremely limited) Unicode support, instead of supplanting it, which primarily translates to embracing rather than shunning the
System.String type wherever possible. Unlike many other text-processing libraries,
Unicode.net does not want you to stop using the system types for string representation and to switch over to custom datatypes 😁.
This post is chiefly directed at .NET developers and others involved in the various stages of .NET deployment, in particular, anyone that’s been keeping tabs on the situation with the new cross-platform, open-source .NET Core initiative or .NET Standard, which came about as Microsoft’s response to the increased fragmentation of the .NET Platform as a result of the myriad of different deployment targets now available. If you’re not into that kind of stuff, feel free to skip this post, or read on and we’ll try to explain things sufficiently as we go through.
When a new Microsoft, with Satya Nadella at the helm, first open sourced the .NET Platform on November 12, 2014 it became clear that they fully intended to put everything they had into the initiative and that great things and big changes were coming to the .NET Framework and its languages. But what it also signaled was the inevitable beginning of a new level of fragmentation for the Framework, which had thus far – by and large – resisted any major fragmentation for the past 12 years of its existence.1 But taking a framework that was cobbled together from parts old and new, built atop of WIN32, GDI, and various Windows-specific anachronisms meant that porting the .NET Framework as-is to other platforms was nigh-impossible — and that major changes would have to be made to support this gargantuan effort.