Because I can never remember them.
This is an honest-to-goodness note to my future self.
Definition: Converting pre-tax 401k and/or IRA money to post-tax Roth IRA money.
Mechanics: Create a rollover IRA account, if you don’t have one. Have the 401k money transferred or distributed to this rollover IRA account. Then convert the rollover IRA money to the Roth IRA. Taxes will have to be paid, and they can’t be paid out of the conversion money, or out of the Roth IRA itself.
When it can be done: After you’ve separated from an employer, or when you’re 59.5 years old.
Definition: Converting post-tax 401k and/or IRA money to post-tax Roth IRA money.
Mechanics: Create a rollover IRA account if one doesn’t exist already. Roll the post-tax money from the 401k to the Roth IRA. This is not a taxable event, because tax has already been paid.
When it can be done: Whenever you want, because it’s post-tax money.
Notes: The IRS allows individuals to contribute some amount of pre-tax money to a 401k, however individuals may contribute more than this limit, up to a second, higher limit. Anything over the first, pre-tax limit has income tax taken out when it’s deposited. It is this post-tax portion that is eligible to go through the mega-backdoor conversion process.
Like many developers, I have collected a bunch of useful methods over time. Most of the time, these methods don’t have unit tests, nor do they have performance tests. Many of them have origins at StackOverflow — which uses the MIT license — and many of them don’t.
I started collecting them formally about two years ago. Recently I decided to actually turn them into something I could consume via nuget, because I was getting fed up with copying and pasting code everywhere.
Haystack targets .NET Standard 1.3, which means it works with:
Constant time string comparison matter in cryptography for various reasons. To that end, fast string comparisons can leak information, so we want to exhaustively check all the bytes in the string, even if we know the strings aren’t equal early on.
|
1 2 3 4 |
const string here = "Here"; const string there = "There"; var areSame = here.ConstantTimeEquals(there); // false |
It’s useful to be able to remove substrings from the beginning and/or end of a string. With or without a StringComparer overload.
|
1 2 3 4 5 6 |
const string trim = "Hello world"; const string hello = "Hello worldThis is a hello worldHello world"; var trimFront = hello.TrimStart(trim); // This is a hello worldHello world var trimEnd = hello.TrimEnd(trim); // Hello worldThis is a hello world var trimBoth = hello.Trim(trim); // This is a hello world |
The library is growing bit-by-bit, and contributions are welcome!
I switched to Firefox recently, which has a “Recommended by Pocket” section on the New Tab page. As I expected, many of the recommendations are productivity fetish articles from Lifehacker and similar rubbish. Their job is not to make you more productive–whatever that means–it’s to keep you reading.
Instead:
If you follow these guidelines, you’ll be happier, less stressed, and deliver more value.
I’ve run ical.net, an RFC-5545 (icalendar) library for .NET since ~May 2016. It’s basically the only game in town if you need to do anything with icalendar-formatted data. (Those .ics files you get as email attachments are icalendar data.)
A lot of these fall into the “pretty obvious” category of observations.
If nothing else, it serves as a historical reference for your own benefit. It also helps your users understand whether it’s worth upgrading. And when your coworkers ask if a version jump is important weeks after you’ve published it, you can point them to the release notes for that version, and they’ll never ask you again.
One of the best things I did when I first figured out how to make a nuget package was push as much into my nuspec file as I could. Everything I learned about various do’s and don’ts was pushed into the code in the moment I learned it.
Not everything in ical.net is automated, and I think I’m OK with that for now. For example, a merge doesn’t trigger a new nuget package version. I think that’s probably a feature rather than a bug.
I suspect I’ll reach a second tipping point where
Scott Hanselman has the right of this:
Keep your emails to 3-4 sentences, Hanselman says. Anything longer should be on a blog or wiki or on your product’s documentation, FAQ or knowledge base. “Anywhere in the world except email because email is where your keystrokes go to die,” he says.
That means I reply to a lot of emails with a variation of “Please ask this on StackOverflow so I can answer it in public.” And many of those answers are tailored to the question, and then I include a link to a wiki page that answers a more general form of the question. Public redundancy is okay.
Accrete your public documentation.
When I took over dday.ical, there were about 70 (out of maybe 250) unit tests that were failing. There was so much noise that it was impossible to know anything about the state of the code. My primary aim was to improve performance for some production issues that we were having, but I couldn’t safely do that without resolving the crazy number of broken unit tests.
The first thing I did was evaluate each and every broken test, and decide what to do. Having a real, safe baseline was imperative, because you never want to introduce a regression that could have been caught.
The corollary to this is that sometimes your unit tests assert the wrong things. So a bugfix in one place may expose an bad assertion in a unit test elsewhere. That happened quite a lot, especially early on.
(So long as your unit tests are passing.)
Pinning down what “smaller” means is difficult. Lines of code may be a rough proxy, but I think I mean smaller in the sense of “high semantic density” + “low cognitive load”.
I think a preference for semantic density is a taste that develops over time.
Given a version number MAJOR.MINOR.PATCH, increment the:
This seems like common sense advice, but by imposing some modest constraints, it frees you from thinking about certain classes of problems:
And by holding my own feet to the fire, and following my own rules, I’m a better developer.
.NET Core is an exciting development. I would LOVE for ical.net to have a .NET Core version, and I’ve made some strides in that direction. But the .NET Core tooling is still beta, the progress in VS 2017 RC notwithstanding. I spent some time trying to get a version working–and I did–but I couldn’t see any easy way to automate the compilation of a .NET Core nuget package alongside the normal framework versions without hating my life.
So I abandoned it.
When the tooling is out of beta, I expect maintaining a Core version will be easier and Core adoption will be higher, both of which improve the ROI with respect to development effort.
Automation, comprehensive unit test coverage with a mandatory-100% pass rate, lower cognitive load, higher semantic density, etc. All these things help you go faster with a high degree of confidence later on.
And if you’re not okay with that, then being a maintainer might not be a good fit for you.
All of these things are common when you run an open source project that has traction. Ask anyone.
I use Dapper for most of my database interactions. I like it because it’s simple, and does exactly one thing: runs SQL queries, and returns the typed results.
I also like to deploy my schema changes as part of my application itself instead of doing it as a separate data deployment. On application startup, the scripts are loaded and executed in lexical order one by one, where each schema change is idempotent in isolation.
The problem you run into is making destructive changes to schema, which is a reasonable thing to want to do. If script 003 creates a column of UNIQUEIDENTIFIER, and you want to convert that column to NVARCHAR in script 008, you have to go back do some reconciliation between column types. Adding indexes into the mix makes it even hairier. Scripts that are idempotent in isolation are easy to write. Maintaining a series of scripts that can be safely applied in order from beginning to end every time an application starts up is not.
Unless you keep track of which schema alterations have already been applied, and only apply the changes that the application hasn’t seen before. Here’s a short, self-contained implementation:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 |
public class SchemaUpdater { private readonly string _connectionString; private readonly ILog _logger; private readonly string _environment; public SchemaUpdater(string connectionString, string environment) : this(connectionString, environment, LogManager.GetLogger(typeof(SchemaUpdater))) { } internal SchemaUpdater(string connectionString, string environment, ILog logger) { _connectionString = connectionString; _environment = environment; _logger = logger; } public void UpdateSchema() { MaybeCreateAuditTable(); var previousUpdates = GetPreviousSchemaUpdates(); var assemblyPath = Uri.UnescapeDataString(new UriBuilder(typeof(SchemaUpdater).GetTypeInfo().Assembly.CodeBase).Path); var schemaDirectory = Path.Combine(Path.GetDirectoryName(assemblyPath), "schema-updates"); var schemaUpdates = Directory.EnumerateFiles(schemaDirectory, "*.sql", SearchOption.TopDirectoryOnly) .Select(fn => new { FullPath = fn, Filename = Path.GetFileName(fn) }) .Where(file => !previousUpdates.Contains(file.Filename)) .OrderBy(file => file.Filename) .Select(file => new { file.Filename, Query = File.ReadAllText(file.FullPath) }) .ToList(); foreach (var update in schemaUpdates) { using (var connection = new SqlConnection(_connectionString)) { try { var splitOnGo = SplitOnGo(update.Query); foreach (var statement in splitOnGo) { try { connection.Execute(statement); } catch (Exception exception) { Console.WriteLine(exception); throw; } } connection.Execute("INSERT INTO SchemaRevision (Filename, FileContents) VALUES (@filename, @fileContent)", new { filename = update.Filename, fileContent = update.Query }); } catch (Exception e) { _logger.Fatal(new { Message = "Unable to apply schema change", update.Filename, update.Query, Environment = _environment }, e); throw; } } } } public static ICollection<string> SplitOnGo(string sqlScript) { // Split by "GO" statements var statements = Regex.Split( sqlScript, @"^[\t\r\n]*GO[\t\r\n]*\d*[\t\r\n]*(?:--.*)?$", RegexOptions.Multiline | RegexOptions.IgnorePatternWhitespace | RegexOptions.IgnoreCase); // Remove empties, trim, and return var materialized = statements .Where(x => !string.IsNullOrWhiteSpace(x)) .Select(x => x.Trim(' ', '\r', '\n')) .ToList(); return materialized; } internal void MaybeCreateAuditTable() { const string createAuditTable = @"IF NOT EXISTS(SELECT 1 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'SchemaRevision') BEGIN CREATE TABLE [dbo].[SchemaRevision] ( [SchemaRevisionNbr] BIGINT IDENTITY(1,1), [Filename] VARCHAR(256), [FileContents] VARCHAR(MAX), CONSTRAINT PK_SchemaRevision PRIMARY KEY (SchemaRevisionNbr), ) END"; using (var connection = new SqlConnection(_connectionString)) { connection.Execute(createAuditTable); } } internal HashSet<string> GetPreviousSchemaUpdates() { using (var connection = new SqlConnection(_connectionString)) { var results = connection.Query<string>(@"SELECT Filename FROM SchemaRevision"); return new HashSet<string>(results, StringComparer.OrdinalIgnoreCase); } } } |
Update 2017-09-05: I added the SplitOnGo() method to support the GO delimiter, since I’ve had occasion to need it recently. It’s adapted from Matt Johnson’s answer on StackOverflow.
Update 2018-04-11: Most all of these changes have been published in ical.net versions 3 and 4. See the release notes for more details.
When I ported ical.net to .NET Core, I removed the ability to download remote payloads from a URI. I did this for many reasons:
HttpClient leaves .NET 4.0 users out in the cold. Choosing to support WebClient brings those people into the fold, but leaves .NET Core and WinRT users out. It also prevents developers working with newer versions of .NET from benefiting from HttpClient.async Tasks. Given the popularity of microservices and ical.net’s origins on the server side, this is a non-starter.We can’t satisfy all use cases if we try to do everything, so instead I’ve decided that we’ll leave over-the-wire tasks to the developers using ical.net.
To that end… strings will be the primary way to work with ical.net. A developer should be able to instantiate everything from a huge collection of calendars down to a single calendar component (a VEVENT for example) by passing it a string that represents that thing. In modern C#, working directly with strings is more natural than passing Streams around, which is emblematic of old-school Java. It’s also more error prone: I fixed several memory leaks during the .NET Core port due to undisposed Streams)
ToString() will be the serializer. It is reasonable for ToString() to serialize the typed representation into the textual representation.Constructors as deserializers buys us…
One of the challenges I faced when refactoring for performance was reasoning about mutable properties during serialization and deserialization. Today, deserialization makes extensive use of public, mutable properties. In fact, the documentation reflects this mutability:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
var now = DateTime.Now; var later = now.AddHours(1); var rrule = new RecurrencePattern(FrequencyType.Daily, 1) { Count = 5 }; var e = new Event { DtStart = new CalDateTime(now), DtEnd = new CalDateTime(later), Duration = TimeSpan.FromHours(1), RecurrenceRules = new List<IRecurrencePattern> {rrule}, }; var calendar = new Calendar(); calendar.Events.Add(e); |
To be completely honest, this state of affairs makes it quite difficult to make internal changes without breaking stuff. Many properties would naturally be getter-only, because they can be derived from simple internals, like Duration above. Yet they’re explicitly set during deserialization. This is an incredible vector for bugs and breaking changes. (Ask me how I know…)
If we close these doors and windows, it will increase our internal maneuverability.
Fluid API
Look at the code above. Couldn’t it be more elegant? Shouldn’t it be? I don’t yet have a fully-formed idea of what a more fluid API might look like. Suggestions welcome.
IICalendarTypeNames
The .NET framework guidelines recommend prefixing interface names with “I”. The calendar spec is called “iCalendar”, as in “internet calendar”, which is an unfortunate coincidence. Naming conventions like IICalendarCollection offend my sense of aesthetics, so I renamed some objects when I forked ical.net from dday. I’ve come around to valuing consistency over aesthetics, so I may go back to the double-I where it makes sense to do so.
CalDateTime
The object that represents “a DateTime with a time zone” is called a CalDateTime. I’m not wild about this; we already have the .NET DateTime struct which has its own shortcomings that’ve been exhaustively documented elsewhere. A reasonable replacement for CalDateTime might be a DateTimeOffset with a string representation of an IANA, BCL, or Serialization time zone, with the time zone conversions delegated to NodaTime for computing recurrences. (In fact, NodaTime is already doing the heavy lifting behind the scenes for performance reasons, but the implementation isn’t pretty because of CalDateTime‘s mutability. Were it immutable, it would have been a straightforward engine replacement.)
CalDateTime is the lynchpin for most of the ical.net library. Most of its public properties should be simple expression bodies. Saner serialization and deserialization will have to come first as outlined above.
VTIMEZONE
The iCalendar spec has ways of representing time change rules with VTIMEZONE. In the old days, dday.ical used this information to figure out Standard Time/Summer Time transitions. But as the spec itself notes:
Note: The specification of a global time zone registry is not addressed by this document and is left for future study. However, implementers may find the Olson time zone database [TZ] a useful reference. It is an informal, public-domain collection of time zone information, which is currently being maintained by volunteer Internet participants, and is used in several operating systems. This database contains current and historical time zone information for a wide variety of locations around the globe; it provides a time zone identifier for every unique time zone rule set in actual use since 1970, with historical data going back to the introduction of standard time.
At this point in time, the IANA (née Olson) tz database is the best source of truth. Relying on clients to specify reasonable time zone and time change behavior is unrealistic. I hope the spec authors revisit the VTIMEZONE element, and instead have it specify a standard time zone string, preferably IANA.
To that end… ical.net will continue to preserve VTIMEZONE fields, but it will not use them for recurrence computations or understanding Summer/Winter time changes. It will continue to rely on NodaTime for that.
URL and ATTACH
As mentioned above, ical.net will no longer include functionality to download resources from URIs. It will continue to preserve these fields so clients can do what they wish with the information they contain. This isn’t a divergence from the spec, per se, which doesn’t state that clients should provide facilities to download resources.
A few months ago, I needed to do some calendar programming for work, and I came across the dday.ical library, like many developers before me. And like many developers, I discovered that dday.ical doesn’t have the best performance, particularly under heavy server loads.
I dug in, and started making changes to the source code, and that’s when I discovered that the licensing was ambiguous, and that it had been abandoned. I was concerned that I might be exposing my company to risk due to unclear copyright, and a non-standard license.
With some effort, I was able to track down Doug Day (dday), and he gave me permission to fork, rename (ical.net), and relicense his library (MIT), which I have done. So I’m happy to report…
mdavid, who saw to it that the library wasn’t lost to the dustbin of Internet history, has graciously redirected dday users to ical.net. Khalid Abuhakmeh, who published the dday nuget package that you might be using (you should switch ASAP) has also agreed to archive and redirect users to ical.net.
So… why should you use the new package?
Doug has revoked his copyright, and given unrestricted permission to give dday.ical new life as ical.net. That means ical.net is unencumbered by legal ambiguities.
My changes to ical.net have been mostly performance-focused. I was lucky in that dday.ical has always included a robust test suite with about 170 unit tests that exercise all the features of the library. Some were broken, or referenced non-existent ics files, so I nuked those right away, and concentrated on the set of tests that were working as a baseline for making safe changes.
The numbers:
There’s no games here. ical.net really is that much faster.
Profiling showed a few hotspots which I attacked first, but those only bought me maybe 3-4 seconds improvement. There was no single thing that resulted in huge performance gains. Rather it was many, many small changes that contributed, quite often by improve garbage collection pauses, many of which were 5ms+, which is an eternity in computing time.
Here are a few themes that stand out in my memory:
Hashtable, ArrayList) to modern, generic equivalentsList<T> to HashSet<T> for many collections, including creating stable, minimal GetHashCode() methods, though more attention is still needed in this area. A nice side effect of this was that lot of lookups and collection operations then became set operations (ExceptWith(), UnionWith(), etc.)O(n^2) methods to O(n) or better by restructuring methods based on information that was available in contextList<T> and Dictionary<TKey, TValue>Foo!) inside a tight loop that’s only ever deserializing Foos. So you can make the call once and just reuse the deserializer.TODOs in the comments.Along the way, I converted a lot of code to modern, idiomatic C#, which actually helped performance as much as any of the discrete things I did above. As I work towards a .NET Core port, I have the runtime down to about 2.8 seconds just through clarifying and restructuring existing code, and idiomatic simplifications.
I found this chart a while back, which I absolutely love, because it makes it easier to reason about what things cost when you’re writing software.
Jeff Dean is famous for paying close attention to these costs in Google’s early days.
Original source was somewhere on Twitter. Alas I don’t remember who.
I didn’t like any of the solutions floating around the web for displaying blocks of text wrapped at word boundaries, so I wrote one.
This:
This is a really long line of text that shoul
dn't be wrapped mid-word, but is
Becomes this:
This is a really long line of text that
shouldn't be wrapped mid-word, but is
Here it is:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
public static string GetWordWrappedParagraph(string paragraph) { if (string.IsNullOrWhiteSpace(paragraph)) { return string.Empty; } var approxLineCount = paragraph.Length / Console.WindowWidth; var lines = new StringBuilder(paragraph.Length + (approxLineCount * 4)); for (var i = 0; i < paragraph.Length;) { var grabLimit = Math.Min(Console.WindowWidth, paragraph.Length - i); var line = paragraph.Substring(i, grabLimit); var isLastChunk = grabLimit + i == paragraph.Length; if (isLastChunk) { i = i + grabLimit; lines.Append(line); } else { var lastSpace = line.LastIndexOf(" ", StringComparison.Ordinal); lines.AppendLine(line.Substring(0, lastSpace)); //Trailing spaces needn't be displayed as the first character on the new line i = i + lastSpace + 1; } } return lines.ToString(); } |