That text about Russia VAT changes I talked about yesterday is from an email I viewed in Win10 Mail. I cut and paste the content, and figured it was HTML format. It was, and MarkUpDown handled it... interestingly.

Here's the raw HTML:

<span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;
mso-fareast-font-family:"Times New Roman"; mso-ansi-language:EN-US;
mso-fareast-language:EN-US;mso-bidi-language:AR-SA'>Russia will become a
Microsoft remittance country where Microsoft (or its billing service provider)
will collect and remit the VAT on behalf of developers. <strong><span
style='font-family:"Segoe UI",sans-serif'>Effective January 1, 2017, Microsoft
will determine the VAT due, withhold such VAT from your App Proceeds, and remit
directly to the Russia tax authorities</span></strong>. The current VAT rate in
Russia is 18%. </span>

The problem comes when we put that into Markdown block format.

> <span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;
> mso-fareast-font-family:"Times New Roman"; mso-ansi-language:EN-US;
> mso-fareast-language:EN-US;mso-bidi-language:AR-SA'>Russia will become a
> Microsoft remittance country where Microsoft (or its billing service provider)
> will collect and remit the VAT on behalf of developers. <strong><span
> style='font-family:"Segoe UI",sans-serif'>Effective January 1, 2017, Microsoft
> will determine the VAT due, withhold such VAT from your App Proceeds, and remit
> directly to the Russia tax authorities</span></strong>. The current VAT rate in
> Russia is 18%. </span>

Bonus for anyone who can figure out the issue.

See how that leaves us with an HTML tag that's split over multiple lines?

> <span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;
> mso-fareast-font-family:"Times New Roman"; mso-ansi-language:EN-US;
> mso-fareast-language:EN-US;mso-bidi-language:AR-SA'>Russia will become a

The Markdown parser handles that quite well, but the > symbols threw off the code I use to align the live preview with the cursor's location as you edit, as it looks like bogus html with all the >'s in the middle. Not great.

So four hours later, I have a fix checked in that seems to be working integrated with MarkUpDown's code (please don't get me started about indie devs' attitudes about (against?) Test Driven Development -- I get that Marco would argue he understands what TDD is, but my guess is he's never actually tried it. That said, I'm not doing it here).

Sure, I also ate and interviewed a programmer in that time, but still... that's a rabbit hole of almost certainly over two hours for a problem only I was likely experiencing.

That's the benefit and danger of being an independent developer. Nobody's going to tell you not to scratch your itch. You're less itchy personally, but that's not always the "best win" for your users.

Labels: app dev, indie, priorities

I recently bumped into @slicknet, a developer for Box who maintains the ESLint project. Here's a quote from ESLint's About page:

The primary reason ESLint was created was to allow developers to create their own linting rules. ESLint is designed to have all rules completely pluggable. The default rules are written just like any plugin rules would be. They can all follow the same pattern, both for the rules themselves as well as tests. While ESLint will ship with some built-in rules to make it useful from the start, you'll be able to dynamically load rules at any point in time.

Here's a good example of when open, pluggable architectures are bad news, and why benevolent dictatorships might still be the best mode of governance.

Questions to ask before deciding on your own linting rules:

1. How many people do you know really know their JavaScript?
2. What percentage of devs at a non-Node shop might those folks represent?
3. How diluted will their voices become when your company decides JS best practices in a committee?
4. Will those rules that your company comes up with really be better than rules from Douglas Crockford?
5. How long did it take for you to come up with those inferior rules?
6. How much time will it take to discuss making changes to those rules in the future?

Answers:

1. Three. Maybe three and a half.
2. Ten percent. If you're lucky.
3. Significantly.
4. No.
5. Hours on hours X number of developers in the meetings.
6. Please, stop it already. You're killing me.

Technically speaking, of course open, pluggable architectures are superior. But in this case, culturally, it's a huge mistake.

Maybe Box's tech stack includes Node, where it's much harder to hide only so-so JavaScript skills, and maybe, in that environment, the openness of ESLint allows them to create something that's no worse than JSLint. But show me one place where JSLint's rules are demonstrably worse than your own (where they can't be turned off with directives) before you argue for ESLint or JSHint.

(That's not to say I don't think ESLint is cool, or that a pluggable interface isn't technically superior to what JSLint offers. But now take your time from questions 5. and 6., and add an obviously smart dude's time maintaining this project. If he's doing it on his own clock, well, more power to you. It's fun to [re]create these sorts of projects, and there's no way to understand a problem better than to live in a "meta-project" like this. My guess is that Mr. Zakas knows his stuff (if I really knew him, I'd have to change #2 to "4-4.5" Or I'd keep it the same, and take myself out). If he's doing it "at work", however, we might have a priorities problem.)

Labels: business, JSLint, priorities