Categories
Blogroll code development search

Microsoft Edge, ungooglability and a new class of bugs

Microsoft definitely has a naming problem. .net core was one thing, but calling a browser Edge was just trolling developers. Try searching for “Edge CSS” or “JavaScript Edge”. It’s a lesson in frustration, which means the bugs in the new browser are extra painful to debug because it’s that much harder to find the blog posts and Q&A for the last person to fix the problem.

And Edge doesn’t behave like IE, or Firefox, or Chrome. I’m sure Microsoft, like the other vendors, are updating OSS frameworks to help them target Edge, but there’s still a lot of Javascript and CSS that breaks silently, so no Console logs to help, no odd numbers in the calculated CSS, and no hacks to persuade Edge that it can render just like the big browsers.

I want to like the browser, I really do. Anything that brings the end of IE closer has to be welcomed, but even after the Anniversary update of Windows 10, it’s far from ready. If I try to open IIS failure logs in Windows 10, it opens up IE, and displays with the correct CSS, and then tells me I should use Edge, where the CSS is broken. It’s frustrating as a user, and as a developer. It’s an alpha product, and it should have been treated as such. Give it to devs, allow power users to opt in, and iterate it. Microsoft still needs to learn what it means to develop in the open.

Documentation

Unfortunately the problem is then compounded by Microsoft’s documentation problem. For all the faults of IE, at least Microsoft had a good reputation for documentation at the height of MSDN. Unfortunately, MSDN is starting to decay, and there’s a number of conflicting alternatives springing up. For us developers, the seemingly preferred route for latest information is blog posts (or the comments thereon – which were the only source of information for a knotty Docker problem we had), but there’s also GitHub, docs.microsoft.com and the occasional update to the existing MSDN documentation suite.

Microsoft seem to be trying to frustrate developers. Especially when they have evolving, and conflicting APIs (I’m looking at you Azure, and the Python vs PowerShell vs Node APIs, and the Portal experience). The documentation experience at Microsoft feels like the Google UI experience before Material Design. And it needs a similar overhaul.

I love seeing Microsoft trying to be more open and I see it working, to a certain extent, in the C# and .Net space, aside from the .Net Core RC release cycle chaos. They’ve come a long way from the days of alt.Net (although I agree that we need to recapture that passion, both for the sake of new developers, and for the sake of keeping Microsoft in check), but they’re in danger of alienating developers once more with the confusion, and the inconsistencies within certain platforms.

In that context, removing project.json and keeping .csproj was the right decision. One clear and consistent path. Now go and apply it across the board.

Categories
code development

Excellent Export, IE and Security

Following on from supporting large Client-side spreadsheets in Chrome, I’ve extended my pull request to also support IE, which uses its own proprietary Javascript method. Because, Microsoft.

And all was good with the world.

Until a Microsoft update broke HTML-formatted XLS files. Because, Microsoft. If you support XLS downloads on your site, and your users are getting a blank Excel window when they try and open them, thank Microsoft, and a security fix. Then go back to using CSV. Or ODS.

Thanks Microsoft.

Categories
code development

Excellent Export and the Chrome URL limit

One key difference between junior and senior developers is that when they encounter a bug, senior developers are much more likely to blame themselves before others, because experience moves you up the Dunning-Kruger curve.

I was given a bug report recently where Chrome was unable to download a particular spreadsheet, and IE didn’t work either. Other spreadsheets worked OK. It was fairly obvious that one feature of this spreadsheet was the likely candidate : it was by far the largest spreadsheet in the system.

I tried to recreate the bug, and I use Firefox, because I prefer the developer tools. And the spreadsheet download worked as expected. So it’s a difference between browsers. It might still be my fault, but it’s looking less likely.

The library we used for the export is a Javascript library called excellentexport, which converts an HTML table into an Excel-compatible spreadsheet. It uses the data: URI scheme to encode the spreadsheet directly into the page, so that the spreadsheet can be generated entirely server-side. Internet Explorer does not support data: so displays the link, but clicking on it has no effect. Chrome and Firefox both support it, but it turns out Chrome reduced the URI limit from (what I think is) 256Mb to 2Mb, and I wasn’t able to see why. This originally caused the tab to crash, and still can under the right conditions, but for URIs just bigger than 2Mb (in our case 3.5Mb), the click is processed, but the data URI is rendered empty, so a null file is downloaded.

This can be a tricky one to diagnose, hence this post. If you ever encounter this, the solution is to switch to CreateObjectUrl, which is supported in all recent browsers, including Edge, but not IE (but as it doesn’t support data: you’re not losing out there). I’ve submitted a Pull Request to excellentexport demonstrating the change required. Worth remembering if you ever need to create a download link client side.

 

Categories
development

Bad change : re-opened tickets and the neverending change

IMAG0085
It goes on and on and on

One reason I don’t trust change is when that change has no defined end goal. When a change is requested, and the ticket completed, but it then enters a cycle of scope-creep that means the ticket can never be closed.

They often start with something simple e.g. “can you improve the performance of this search”, with a simple tweak – add a JOIN clause to avoid SELECT 1+n queries. In some cases the user acknowledges the improvement, but some users will start pushing new features against the request “because it’s in the same area”. After all, changing the colour of the links on the search page is still part of the same use case, right? And the fact the search is still slow when I use this rare combination of fields means the original ticket wasn’t fixed.

Close it and move on

In some scenarios, it’s easy to be brutal. These are time-bounded sprints, so anything raised must be factored in. This works where features and bugs are interchangeable and represent simply “work to be done”, however they are charged, and let the retrospectives and other analysis worry about whether any particular piece of work is a bug or a feature, so that the team can ensure it’s delivering the best business value.

The definition of done needs to be clear from the ticket (although maybe not to the detail of a SMART objective, it’s worth thinking about that framework). If the provided steps no longer produce an incorrect result, or a speed improvement is recorded, or some other pre-defined success criteria is met, then the ticket is done. Any further discussion is a new ticket. If the objectives aren’t met, it should not be marked as done and the developer should continue work on it.

It’s under warranty

Many software products and projects have a grace period of warranty, where bugs are fixed for free. This is typically useful to resolve conflicts in untested combinations, or volumes, but it can also be used as a stick if the developers aren’t careful. Provided the warranty period is reasonable for the size, complexity and support arrangements within the project, bugs should be fixed to ensure the original scope is delivered. Some customers will however try to extend scope by issuing bug amendments to change scope, under the guise that the bug was raised during the warranty period is therefore should be resolved. After all, bugs should be fixed, but features must be paid for.

Make sure you have a good rapport with your client, and make sure the terms are clear.

Decide now what done means, and how to manage tickets

The last thing you need is to decide this when the tickets that’s blocking the release gets re-opened for the 100th time because the CSS is broken in IE6.

What does it mean to be done?

What constitutes a failure?

Can the software be released as it is?

Categories
code development programming

HTML5 and the Beta Browsers

I’ve dug out my HTML5 talk again, as I’ve been invited to present at TechMeetup in Glasgow on Wednesday. As I now use FireFox 4 Beta as my main browser (App tabs and Panorama are too good to give up), I’ve been trying to get my presentation, written in HTML5, working on it, and on the Internet Explorer 9 beta. I also tried the it on the latest release versions of Chrome and Opera. Oddly, Opera is the only browser not to display anything, given that the S5 presentation framework I use is ultimately based on an Opera demo. This may be something I have broken in the template. Opera is stuck playing the loading screen.

The presentation (that I will upload after the talk) now validates according to the W3C validator. Chrome, Firefox and IE all display the content, and all hide content when moving to the next slide, but Chrome and FireFox format the content to fit on the screen whilst IE simply lists the content. The CSS3 demos do not work in IE, suggesting that CSS may be part of the problem, although the CSS support in IE9 is light years ahead of previous versions. Certainly it appears that the layout model on IE is different enough from that used by Chrome and Firefox to merit having to redesign any site for IE. Since the w3c does not publish a rendering validator, I will not comment on which one is most standards compliant. I will merely say that even in the brave new world of HTML5 and CSS3, where rendering is more strictly defined, web development will still need to be done to the lowest common denominator.

Of the new HTML5 features in my demo, FireFox 4 has some changes to svg handling which interferes with the inline svg in my presentation, and has tidied up the UI for features such as geolocation from the previous version. Other parts of my presentation are held back by the lack of FireFox 4 support for some of the extensions I use. In particular, certain aspects of FireBug and Web Developer I use for live editing either do not work at all or are unavailable for local pages (I’m not sure which). IE follows Chrome and FireFox in not offering support for the new form input types, in partcular date and datetime. Given the problems datepickers are giving me in my day job, this is a big disappointment to me. I notice that IE, like Chrome does not animate PNG files such as the ones here, but unlike Chrome, also has the wrong background colour. IE is also the only one of the 4 browsers not to support the Mozilla <video> demos – although youtube html5 does appear to work, so this could be a codec issue. I don’t currently have access to Safari to see how well that does – I suspect it too will fail.

IE9 does have some good debugging support through its F12 Developer Tools, and, whilst the add-ons catch up, IE9 is easier to use to debug web pages than FireFox 4. Browsing through remy’s html5 demos, it looks like content-editable is more persistent than in should be in IE, because editing that page seems to persist the lifetime of the tab. Still, that’s why it’s a beta. I’m also disappointed to see that the Offline Application Manifest is not supported, as that would seem to be the perfect partner to the pin-to-taskbar functionality. Still, I’m happy to see support for canvas and inline svg, particularly given FireFox’s problems, although I hoped for a higher score on the HTML5 test (where it gets less than 100 compared to 159 for Opera and over 200 for Firefox and Chrome) and the ACID3 test (where 95 beats FireFox on 91 but falls behind Chrome and Opera on 100).

Now that I’ve finally got my hands on IE9, I’m less excited by it than I am by Chrome and FireFox. It looks as if it will still need plugins (Silverlight?) for rich internet applications, meaning that developing a full cross-platform web application means either limiting functionality for certain browsers (which will need to be done for IE6 for a while yet anyway), or writing a plugin for IE to bring it up to the level of the other desktop and smartphone browsers.

Given the pace of releases, I’m surprised how little new I can add to my presentation. Whilst every browser is moving forward, the baseline standard still appears to be where it was, there’s no cross-browser video format, no cross-browser forms support (input types or validation), no cross-browser Web Application support, no cross-browser geolocation support and no cross-browser CSS transforms. In fact, the canvas and structural elements seem to the only features in my survey with cross-browser support, and given the poor showing of canvas in the results, it’s going to be a long road to adoption, unless you’re in the mobile space.