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.
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.
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.
We’ve raved about Microsoft’s latest take on a Linux subsystem for Windows, this time in the form of the oddly-dubbed “Bash on Ubuntu on Windows” Windows Subsystem for Linux — herein and forever after referred to only as WSL for the sake of our collective sanity — but as awesome as being able to type
bash in a command prompt to get access to holy posix goodiness, we think we can do better. Meet
$, formally known as
RunInBash, is a simple command line helper utility that simply runs whatever follows it under WSL rather than in the current (Windows) terminal. Here’s a picture to illustrate (click to expand):
Dedicated followers (and anyone making the switch from Mac to PC) – this Pi Day 2017 gift is just for you! A new day means a new free app for our favorite peeps on the internet. Meet Easy Window Switcher, our invisible window cycling utility that makes it ridiculously easy to jump between windows of the same application à la OS X with the alt` (alt-backtick) keyboard shortcut.
Easy Window Switcher (codename wincycle) imbues your Windows PC with the same superpowers that were once exclusively reserved for the ranks of Apple’s OS X users. With Easy Window Switcher, you don’t need to muck around with alt-tab trying to find the window you’re looking for amongst 40 or 50 others1 – just hold down the alt key and backtick away to your heart’s content. And moving backwards is as easy as
1, 2, 3 altshift` and done.
Dell has two top-of-the-line laptops that are currently competing for king-of-the-hill status — quite the odd choice from a marketing perspective, no doubt — but how do the two compare? We take a look at both the XPS 15 (9560) and the Precision 5520 and see how they stack up against one-another.
The 2017 XPS 15 9560 and the 2017 Precision 5520 are both “flagship” laptops out of Dell’s prosumer and business divisions respectively, and while they share a chassis and similar specs, they aren’t exactly two faces of the same coin. While on the entry level both can be similarly configured, the XPS 15 comes in one of seven different configurations (or eight if outside the USA), while the Precision 5520 can be hand-customized in any of a dozen+ configurations depending on your (small business) needs. The real difference between the two comes into stark visibility when comparing the top-end options between the two lines, however.
Let’s say you’ve got a terminal open and you want to sort the contents of a file before you email it to a friend. The file can contain anything and it could be of any length, it doesn’t matter. What do you do?
The obvious answer is to use
sort. Sorting the file is as easy as
sort myfile – except it doesn’t actually sort the file, it sorts the *contents* of the file and dumps them to the command line (via
stdout). So how do you sort the file “in-place,” so-to-speak? Again, the obvious answer would be
sort myfile > myfile,1 redirecting the output of the sort command back to the file you want to ultimately send sorted.