Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2016

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white.

Friday, October 14, 2016
Microsoft HTML Clipboard formats: All you ever wanted to know, but were afraid to ask. And then some. Let's talk HTML Fragments in your clipboard when coding on Windows. I've created what's arguably the best Markdown editor on Win10 (if I do say so myself), and wanted it to be more intelligent when I was pasting content that comes from web browsers. That is, in the original version of MarkUpDown, if you copied the text I've got highlighted, below, from DaringFireball... ... and you pasted it into MarkUpDown as a quotation (Ctrl-Shift-V), you'd get unstyled text, like this... > Mossberg: > For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer. > Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone. > These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, they stop trying. I mean, that's okay-ish. Unfortunately, you'd have to go put in an additional line after each line so that it's not all scrunched into one paragraph. And you lose that Gruber was block-quoting Mossberg. And you lose that "they stop trying" was originally in italics. That stinks. Isn't Markdown really supposed to be shorthand for html? Can't we handle pasting html better than that? Yes, yes we can... TL;DR Go pull the HtmlFragmentHelper, a working, in-progress library for turning HTML Fragment strings into view models with these properties... `public class HtmlFragmentViewModel { public string Version = ""; public int StartHtml = int.MinValue; public int EndHtml = int.MinValue; public int StartFragment = int.MinValue; public int EndFragment = int.MinValue; public string SourceUrl = ""; public string FragmentSourceRaw = ""; public string Error = ""; //... }` There are also several convenience methods to help you get, say, the top- and second-level domains for the HTML Fragment's source URL (`example.com` from `http://blog.example.com/user/blog0000231.html`), or just the html from the selected fragment (`myHtmlFragmentViewModel.FragmentSourceParsed`), etc. Here's an example: `public string CreateQuote(string htmlFragmentSource) { string strIntroLink = string.Empty; HtmlFragmentViewModel vm = new HtmlFragmentViewModel(htmlFragmentSource); if (vm.SourceUrl.Length > 0 && vm.SourceUrlDomainSecondAndTopLevelsOnly.Length > 0) { strIntroLink = string.Format("From <a href=\"{0}\">{1}</a>:" + Environment.NewLine + Environment.NewLine, vm.SourceUrl, vm.SourceUrlDomainSecondAndTopLevelsOnly); } return strIntroLink + vm.FragmentSourceParsed; }` Read how to use it here. Get it from GitHub, though the only file you really need is here. And here's a quick article on how to get code back into the clipboard as html, which I'm not doing. HTML Fragment Format Want to paste clipboard HTML as HTML? Enter Microsoft's HTML clipboard format. Instead of using the standard code to read the clipboard's contents, like this... `string clipboardText = await Clipboard.GetContent().GetTextAsync();` ... now you use this... `string htmlClipboardText = await Clipboard.GetContent().GetHtmlFormatAsync();` But when you look at the contents of `htmlClipboardText`, you quickly notice that strange things are afoot at the Circle K. What comes back isn't a string with html source, but an "HTML Fragment" formatted string that looks like this: HTML Fragment from Edge Version:1.0 StartHTML:000000210 EndHTML:000003550 StartFragment:000002696 EndFragment:000003500 StartSelection:000002696 EndSelection:000003496 SourceURL:http://daringfireball.net/2016/10/mossberg_siri <!DOCTYPE HTML> <HTML lang="en"><HEAD> <!-- Open Graph [jive] --> <!-- <meta property="og:site_name" content="Daring Fireball" /> <meta property="og:title" content="Walt Mossberg: ‘Why Does Siri Seem So Dumb?’" /> <meta property="og:url" content="http://daringfireball.net/2016/10/mossberg_siri" /> <meta property="og:description" content="In addition to the engineering hurdles to actually make Siri much better, Apple also has to overcome a “boy who cried wolf” credibility problem." /> <meta property="og:image" content="https://daringfireball.net/graphics/df-square-192" /> <meta property="og:type" content="article" /> --> <!-- Twitter Card [jive] --> <TITLE>Daring Fireball: Walt Mossberg: ‘Why Does Siri Seem So Dumb?’</TITLE> <LINK href="/graphics/apple-touch-icon.png" rel="apple-touch-icon-precomposed"> <LINK href="/graphics/favicon.ico?v=005" rel="shortcut icon"> <LINK href="/graphics/dfstar.svg" rel="mask-icon" color="#4a525a"> <LINK href="/css/fireball_screen.css?v1.7" rel="stylesheet" type="text/css" media="screen"> <LINK href="/css/ie_sucks.php" rel="stylesheet" type="text/css" media="screen"> <LINK href="/css/fireball_print.css?v01" rel="stylesheet" type="text/css" media="print"> <LINK href="/feeds/main" rel="alternate" type="application/atom+xml"> <SCRIPT src="/mint/?js" type="text/javascript" async=""></SCRIPT> <SCRIPT src="http://www.google-analytics.com/ga.js" type="text/javascript" async=""></SCRIPT> <SCRIPT src="/js/js-global/FancyZoom.js" type="text/javascript"></SCRIPT> <SCRIPT src="/js/js-global/FancyZoomHTML.js" type="text/javascript"></SCRIPT> <LINK title="Home" href="/" rel="home"> <LINK href="http://df4.us/pfz" rel="shorturl"> <LINK title="Apple Responds to Dash Controversy" href="http://daringfireball.net/2016/10/apple_dash_controversy" rel="prev"> <SCRIPT src="http://daringfireball.net/mint/?record&key=383950464d37374b39333637695970466458724e6779513431&referer=&resource=http%3A//daringfireball.net/2016/10/mossberg_siri&resource_title=Daring%20Fireball%3A%20Walt%20Mossberg%3A%20%u2018Why%20Does%20Siri%20Seem%20So%20Dumb%3F%u2019&resource_title_encoded=0&window_width=1756&window_height=921&resolution=2438x1371&flash_version=0&1476397798179&serve_js" type="text/javascript"></SCRIPT> </HEAD><BODY onload="setupZoom()"><DIV id="Box"><DIV id="Main"><DIV class="article"><!--StartFragment--><P>Mossberg:</P><BLOCKQUOTE><P>For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer.</P><P>Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone.</P></BLOCKQUOTE><P>These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, <EM>they stop trying</EM>.</P><!--EndFragment--></DIV></DIV></DIV></BODY></HTML> Wow. No, really, wow. That surprised me. I was using Edge this time instead of Chrome, and whoa. Edge includes the entire page's header. That said, that's really not a horrible idea. We have really good context for this fragment, and if we wanted the original CSS, for example, we know where to get it. Aside: Look at the info DaringFireball's sucking in: `resolution=2560x1440& flash_version=0& 1476452395012& serve_js` Gruber doesn't use Flash. Kinda Panopticlicky, ain't it? Looks like it's supporting this. Another Aside: Internet Explorer 11 creates the same fragment source, so if you think Edge was created from the ground up... Interestingly, the old Internet Explorer copyright box used to reference Mosaic, but that's gone in IE11. Wonder if IE11 is really the child of IE6 and 7? But enough aside-ing... HTML Fragment from Chrome But let's take a look at where I initially started, with Chrome. Version:0.9 StartHTML:0000000164 EndHTML:0000002719 StartFragment:0000000200 EndFragment:0000002683 SourceURL:http://daringfireball.net/2016/10/mossberg_siri <html> <body> <!--StartFragment--><p style="margin: 0px 0px 1.6em; padding: 0px; color: rgb(238, 238, 238); font-family: Verdana, "Bitstream Vera Sans", sans-serif; font-size: 11px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(74, 82, 90);">Mossberg:</p><blockquote style="font-size: 11px; margin: 2em 2em 2em 1em; padding: 0px 0.75em 0px 1.25em; border-left: 1px solid rgb(119, 119, 119); border-right: 0px solid rgb(119, 119, 119); outline: 0px; vertical-align: baseline; background: rgb(74, 82, 90); color: rgb(238, 238, 238); font-family: Verdana, "Bitstream Vera Sans", sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-t ransform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><p style="margin: 0px 0px 1.6em; padding: 0px;">For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer.</p><p style="margin: 0px 0px 1.6em; padding: 0px;">Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone.</p></blockquote><p style="margin: 0px 0px 1.6em; padding: 0px; color: rgb(238, 238, 238); font-family: Verdana, "Bitstream Vera Sans", sans-serif; font-size: 11px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacin g: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(74, 82, 90);">These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems,<span class="Apple-converted-space"> </span><em>they stop trying</em>.</p><!--EndFragment--> </body> </html> See the difference? Chrome's fragment initially looks much more focused, but also provides much less information about the code's original context. Worse, Chrome's puts all the CSS information inline, and repeating each CSS property inside of each pasted html element makes the source a long ways away from DRY. And that out-of-context, inline CSS is lossily translated, which will cause us some rendering problems that we'll see and discuss in a bit. Original Source Now Edge's fragment isn't perfect. Here's the original html of that snippet straight from the server... <p>Mossberg:</p> <blockquote> <p>For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer.</p> <p>Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone.</p> </blockquote> <p>These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, <em>they stop trying</em>. NOTE: There's no closing `</p>` tag because I've cut the source at that spot. Look how clean the original is! Why can't we just get that? Chrome's CSS injections and line flattening makes for a much less human readable snippet. Edge is close, but still weird. Take another look. For some reason, Edge's fragment makes every tag uppercase like it's 1998. It also trashes Gruber's original (and thoughtful) whitespace. Also yuck. I mean, Gruber's using Markdown to write Daring Fireball. In a perfect world, I'd take that clipboard's html and turn it back into Markdown when it's pasted into MarkUpDown. How do we get this original source? Start and End Fragment The important thing to catch is that the HTML Fragment format almost always includes a full html doc with html and body tags after the `SourceURL` and other metadata. Within that html code, there are markers, `<!--StartFragment-->` and `<!--EndFragment-->`, saying where the exact selection started and stopped. Though Chrome immediately dives into your selected text (the "true" html fragment) immediately after the `<body>` tag, Edge gives you any open tags that come before your fragment too. In this case, you had three open `div` tags when you got to the highlighted selection: `<DIV id="Box"><DIV id="Main"><DIV class="article">`. Knowing this DOM could be really helpful if you were interested in retrieving the original CSS and formatting your fragment as close to the original markup as possible. If you ignore context like this, though, it's an easy enough feat to take the string and parse out the "true fragment's" html by splitting the entire HTML Fragment string on `<!--StartFragment-->` and `<!--EndFragment-->`. Here's an early version of something I wrote to just take out the html, ignoring all the fragment metadata. private string _parseHtmlClipboardFragment(string rawFragmentSource) { string ret = rawFragmentSource; string delimiterStartAfter = "<!--StartFragment-->"; string delimiterEndBefore = "<!--EndFragment-->"; if (-1 < ret.IndexOf(delimiterStartAfter)) { ret = ret.Substring(ret.IndexOf(delimiterStartAfter) + delimiterStartAfter.Length); if (-1 < ret.IndexOf(delimiterEndBefore)) { ret = ret.Substring(0, ret.IndexOf(delimiterEndBefore)); } else { ret = string.Empty; // No luck, Ending not after Start; go back to nothing. } } return ret; } NOTE: I've got a nice library that parses all this up into a custom html fragment view model that I mentioned in TL;DR. I wouldn't and don't use the above code in most cases. When we parse out that html and insert it into our Markdown from Chrome, however, we get some, um, interesting results. NOTE: Remember that Markdown is a superset, so to speak, of html. You could have a "Markdown" file without any Markdown syntax that's pure html. So what I'm really saying is, "Let's see what those html snippets that we pulled from the fragment look like when they're injected into our regularly scheduled html." I'm going to wrap these pastes in `blockquote` tags so that you can tell where they start and stop easily. Edge Parsed Code Mossberg: For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer. Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone. These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, they stop trying. Though you should remember that the original source has been smeared together, losing its newlines, and all the tags are strangely capitalized, the source looks pretty nice. It's plain, and adopts the local styling for the most part, but the most important markup is still there -- the blockquote, the italics, links if they'd been included, etc. Chrome Parsed Code Mossberg: For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer. Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone. These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, they stop trying. Um, ew. Wha' happen'd? Unfortunately, even though Daring Fireball's entire page has the same styles applied, this inline kludge Chrome performs puts it only in each, in this case, `<p>` tag. So when we have a margins around paragraphs, there's nothing telling us to also put that color and style between the block-level tags. There's no surrounding tag to be a stand-in for, essentially, the `body` (or any other lost, open) tag. Let's look at all the overhead we have for each `p` from that fragment: `<p style=" margin: 0px 0px 1.6em; padding: 0px; color: rgb(238, 238, 238); font-family: Verdana, "Bitstream Vera Sans", sans-serif; font-size: 11px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(74, 82, 90); ">` And here's what we have from Chrome's Dev Tools' "Computed" style tab: `color: rgb(238, 238, 238); display: block; font-family: Verdana, "Bitstream Vera Sans", sans-serif; font-size: 11px; height: 19px; line-height: 19.8px; margin-bottom: 17.6px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-size-adjust: 100%; width: 425px; -webkit-margin-after: 17.6px; -webkit-margin-before: 0px; -webkit-margin-end: 0px; -webkit-margin-start: 0px;` But note that that's essentially all from one css file, as properties from user agent stylesheets are simply the browser's defaults: If you'd like, we can compare the fragment's CSS vs. the stylesheet. Spoiler: It's a mess. Not a lot of matching. Click here to see. Ugly. The bottom line is that `background-color: rgb(74, 82, 90);` is something that belongs to the body, but is inserted here by Chrome into its HTML Clipboard contents as something that's attached to each block element. That's wrong. It doesn't display correctly, and it needlessly clutters the resulting HTML. With HtmlFragmentHelper, I have a couple of choices. One is to strip all inline styles out, or at least some subset of styling. If I want to maintain as much of the original as possible, I might just blast anything that injects colors into the html, like `color` and `background-color`. Or I could blast all the inline style info and get something more like Edge's code. Or I could normalize the CSS and optionally (via a property on `HtmlFragmentViewModel`) wrap it all in a block-level tag that contains CSS that's everywhere. Or at least in all of the top-level tags. But now I'm starting to write an html parser, which is a little outside of my current scope. I think I'm going to do the former, though it's not in there as of this writing. That Chrome paste looks horrible as is, though. If only there was an easier way... HTML Fragment from Firefox There are certainly other applications that create HTML Clipboard values. I ran into LibreOffice's when using Calc, their spreadsheet app, and its html clipboard doesn't include Start and EndFragment tags. Wonderful, folks, wonderful. But isn't there one glaring omission I might want to add here? You know, I think there is at least one... For fun, let's take a look at Firefox's fragment too. Firefox isn't as popular as it used to be, but it's probably worth taking a look. (Remember that this is all on Windows, and Safari is dead enough by now that I'm not going to bother with v5.) Version:0.9 StartHTML:00000156 EndHTML:00001060 StartFragment:00000190 EndFragment:00001024 SourceURL:http://daringfireball.net/2016/10/mossberg_siri <html><body> <!--StartFragment--><p>Mossberg:</p> <blockquote> <p>For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer.</p> <p>Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone.</p> </blockquote> <p>These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, <em>they stop trying</em>.</p><!--EndFragment--> </body> </html> Oh, so beautiful. Same whitespace as the original, with the added bonus (?) that the final paragraph is also text wrapped. No crazy inline CSS attempted. No header overhead or 1998-style HTML TAGS. You could argue that Chrome is better because it has that inline CSS (yuck!) or Edge because it has the full page headers, but honestly, we're only one step farther away from what Edge gave us. We have the URL here. If we have network access to get CSS, we have network access to read the header and figure out where the CSS lives ourselves. Don't overcomplicate things. Beautiful. Good looking code continues to look good when pasted inline with Markdown. Firefox Parsed Code And Firefox's snippet is just as nice when pasted. Mossberg: For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer. Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone. These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, they stop trying. I miss Firefox. Labels: c#, howto, html, long, markdown, markupdown, microsoft, tutorial posted by ruffin at 10/14/2016 11:46:00 AM
0 comments

Thursday, October 13, 2016
Siri QA is broken From daringfireball.net: Mossberg: For instance, when I asked Siri on my Mac how long it would take me to get to work, it said it didn’t have my work address — even though the “me” contact card contains a work address and the same synced contact card on my iPhone allowed Siri to give me an answer. Similarly, on my iPad, when I asked what my next appointment was, it said “Sorry, Walt, something’s wrong” — repeatedly, with slightly different wording, in multiple places on multiple days. But, using the same Apple calendar and data, Siri answered correctly on the iPhone. These sort of glaring inconsistencies are almost as bad as universal failures. The big problem Apple faces with Siri is that when people encounter these problems, they stop trying. Exactly right. I've had it do the same thing when I ask Siri to give me directions home, usually because I want to know if there's enough traffic to go an alternate route, and I get the same, "Who are you?!" complaint. But if I open Maps, "Home" is usually the first location listed. QA sucks at Apple. I'm no longer politely questioning it. Spend ten million (he said figuratively) and get the best QA staff in the business, and make sure there's no silo making QAing app interactions an issue. If Maps borks like this, the QA team "for Maps" has to be able to hold Siri and Contacts (or whatever else) accountable. No software ships until this blocking bug is fixed. Good QA will think of and try these sorts of pretty obvious, yet creative, use (not edge, simply "use") cases before you ship. Pitiful. Seriously pitiful. Labels: apple, applefail, coding, qa, quality, siri posted by ruffin at 10/13/2016 02:38:00 PM
0 comments

Wednesday, October 12, 2016
Hey Nate Silver: "Men" isn't monolithic From FiveThirtyEight.com But it seems fair to say that, if Trump loses the election, it will be because women voted against him. I'm slowly starting to see what it feels like to be lumped into a demographic. Between this, "locker room talk", and "mansplaining", I'd really like us to find a less socially coercive version of the concept of "gentlemen" that we could use to split the monolithic "men" into at least two groups. Or whatever term you want. I'm probably a little biased here. "Unconventionally sensitive XYs." Whatever. Let's look at Nate Silver's numbers: For heaven's sake, Nate, there are three polls with men voting for Clinton ahead of Trump. Overall, it's a five point swing average. I guess that means Trump 40% and Clinton 35% or therebouts, with 25% undecided or 3rd partied, just to throw a dart at the wall. That means 7/8^th as many men are voting for Clinton as Trump according to Silver's numbers. That's a crudload of XYs. Further, it'd be in spite of 40% of women voting for a major party voting for Trump. (I'm trying to stay reasonably impartial in my presentation here, but wow. Just wow.) In other words, If Trump loses the election, it's not because men voted for him. It's not because women voted against him. It's because the country voted against him, and he lost. And vice versa if Clinton loses. If you wanted to say what Silver tried with more skill, it'd be to say, "If Trump loses the election, it's because his lead with men was larger than Clinton's lead with women." Stop normalizing me, dang it. Every American without two X chromosomes isn't voting for Trump, and, strangely enough, everyone with isn't voting for Clinton. Labels: gruber, Other Stuff, politics posted by ruffin at 10/12/2016 05:43:00 PM
0 comments

Tuesday, October 11, 2016
Spaghetti code leads to suffering From Microsoft's How to: Verify that Strings Are in Valid Email Format Oh please, heavens, say it isn't so. EDIT: Some decent advice: Defence in depth only works if each level of your security onion is not rotten. One rotten layer means you spoil the whole onion. Rejecting "foo@example.com.au" because you want to defend against vulnerabilities in Sun's µ-law encoding doesn't make sense, does it? Don't laugh, it's happened to me. The reason I am here commenting is that Medicare Australia doesn't allow ".au" addresses, only ".com". Also read Mark Swanson, "How not to validate email, ", mdswanson.com/blog/2013/10/14/… – ManicDee Nov 22 '13 at 5:21 And then from the linked post, "How now to validate email": Or maybe you will find a regular expression that looks something like `^[_a-z0-9-]+(\.[_a-z0-9-]omg-whyyyyy$`. ... So what should you do instead? Just check for the existence of @. Every email address will have at least one of them and it is trivially easy to write this code. As I mentioned on SO... The buttoned up coder in me is trying to resist, but the rest is surprisingly convincingly arguing that anything else is a sad tragedy of micro-optimization. Just fwiw, I'm also checking for a length of at least one before and after the last `@`, though I haven't looked at the format for comments inside of an email address [sic!!]. `public static bool IsValidEmail(this string str) { // See https://myfreakinname.blogspot.com/2016/10/spaghetti-code-leads-to-suffering.html#emailValidationEdit // for the reasoning behind this. int lastAtLoc = str.LastIndexOf('@'); return lastAtLoc < str.Length - 1 && lastAtLoc > 0; }` Labels: code, microsoft, style, yoda posted by ruffin at 10/11/2016 02:40:00 PM
0 comments

Friday, September 23, 2016
Encrypted data still wants to be free "At Least 500 Million Yahoo Accounts Hacked in Late 2014" via Macrumors. Yahoo today confirmed that "at least" 500 million Yahoo accounts were compromised in an attack in late 2014, leaking customer information like names, email addresses, telephone numbers, birthdates, hashed passwords, and both encrypted and unencrypted security questions and answers. Does this surprise anyone at this point? You know, I think if I had a huge cloud company with hundreds of millions of users, I'd consider having at least three sets of teams writing at least the fascade of the software -- the server-side controller methods -- so I could rotate from one to another every sprint or so to throw off would-be hackers. As soon as they made progress hacking one, it'd be replaced by Team 2. By the time we got back around to Team 1, they'd have iterated once or twice, and the hackers would have to, if not start over, pivot. Or maybe any user would have an X% chance of bringing up Team 1, Y% 2, Z% 3 each time they started a session. I'd likely do the same for the users' data, splitting them into into several different databases, and maybe rotating users back and forth. Several different architectures using several different databases, all pitching to a consistent UI and user experience. If you interface well, it's no problem. I realize there are obvious downsides. Maybe Team 2 has a horrible design, and it's easily cracked. That is, I'm in some sense three times as likely to get hacked as before, even if it's a much smaller set of users that's compromised. But even more importantly would seem to be to sniff your network traffic like heck to see when 500 million sets of birthdays had left the network. Bizarre. Ultimately, though, RMS (hrm, apparently not Stallman) is on point: If it's on a computer, in a network, given enough time, it'll eventually be free to anyone else on that network. Networked zeroes and ones want to be free. Labels: encryption, free, rms, security, yahoo posted by ruffin at 9/23/2016 12:19:00 PM
0 comments

Wednesday, September 21, 2016
A Leica, Rolex, and Coke walk into a bar... From DaringFireball: A new Rolex needs to look like a Rolex. A Leica needs to look like a Leica. A new Coca-Cola bottle needs to look like a Coca-Cola bottle. I mean, I get the point that each is iconically designed, generally, but, um... Put another way, Andy Warhol would've only included one of those in his pop-art series (mais quelle ironie, non?) Labels: design, gruber posted by ruffin at 9/21/2016 08:38:00 AM
0 comments

Monday, September 19, 2016
Serious threats from the IRS The only thing I can do is wish you a good luck as the situation totally unfolds on you. They had me up until that poorly translated line. (Okay, no, no they didn't. But it was a hilarious/horrible ending. If you're going to pay to robocall tons of people, you might as well translate your threat properly first.) posted by ruffin at 9/19/2016 01:06:00 PM
0 comments

All posts can be accessed here:

Just the last year o' posts:

URLs I want to remember:
* Atari 2600 programming on your Mac	* joel on software (tip pt)
* Professional links: resume, github, paltry StackOverflow	* Regular Expression Introduction (copy)
* The hex editor whose name I forget	* JSONLint to pretty-ify JSON
* Using CommonDialog in VB 6	* Free zip utils
* that hardware vendor review site I forget about is here	* Regex Tester
* Read the bits about the zone	* Find column in sql server db by name
* Giant ASCII Textifier in Stick Figures (in Ivrit)	* Quick intro to Javascript
* Don't [over-]sweat "micro-optimization"	* Parsing str's in VB6
* .ToString("yyyy-MM-dd HH:mm:ss.fff", CultureInfo.InvariantCulture); (src)	* Break on a Lenovo T430: Fn+Alt+B
email if ya gotta, RSS if ya wanna RSS, ¢ & Δ if you're keypadless

About Our Author

TL;DR

HTML Fragment Format

HTML Fragment from Edge

HTML Fragment from Chrome

Original Source

Start and End Fragment

Edge Parsed Code

Chrome Parsed Code

HTML Fragment from Firefox

Firefox Parsed Code