Thankfully, the fix isn’t painful — it’s just frustrating that it needs to be done.

I’ve seen suggestions to use the old-school DOS 8.3 file paths, but I prefer to use something that still reads well and maps to other dev command line tools on my workstation.

I created a directory junction in an existing folder C:\Dev:

mklink /d c:\Dev\Anaconda3_64 "c:\Program Files (x86)\Microsoft Visual Studio\Shared\Anaconda3_64"

Specifically, I created:

C:\Dev\Anaconda3_64

which is a junction to:

c:\Program Files (x86)\Microsoft Visual Studio\Shared\Anaconda3_64

You can use any junction directory you want, but remember that it can’t be too long, or you’ll have the same problem with a different name/path. :) When using mklink, be sure to quote the path for the Anaconda install in the Visual Studio directory as shown above in the mklink example.

Next, I updated the command prompt with the new path:

c:\Dev\Anaconda3_64\pythonw.exe C:\Dev\Anaconda3_64\cwp.py C:\Dev\Anaconda3_64 %windir%\system32\cmd.exe /k c:\Dev\Anaconda3_64\Scripts\activate.bat c:\Dev\Anaconda3_64

Of course, you’ll need to substitute the path you used (just copy and paste into Notepad and do a quick search and replace with the full path I used).

It should start up without issue now.

The decorator takes a constructor/class which could be used how ever you’d like (or substituted for something else entirely).

View the code on Gist.

I created a React Native project, ejected it, and then converted it to use TypeScript. Things were going well until I started to use MobX. The following error occurred:

node_modules/mobx/lib/utils/utils.d.ts(1,23): error TS2688: Cannot find type definition file for 'node'.

Something as simple as:

import { observable } from "mobx";

/// <reference types="node" />

yarn add -D @types/node

Here‘s the code. I used a standard Flutter app template and also added a few packages to the project.

I’ve coded a substantial amount of Windows Presentation Foundation (WPF) and Silverlight code over the years. One of the concerns that often came up was the UI tree …, the more complex it was, the slower the app often was without lots of tricks. Using the new inspector for Flutter apps, I selected one of the images in the UI. Needless to say, there are a few objects created to represent the UI tree. In fact, I had trouble capturing the image for this blog post. :)

I don’t have evidence that this generally will be a performance problem. Maybe with relatively simple mobile applications, a deep rich object based UI hierarchy won’t affect performance as much as it might in a desktop application of reasonable complexity. Regardless, it’s worth considering as you build a UI.

Back to what I built. When a user taps on a board game in the list, I’ve wired the code to call the _showGameItem below. I appreciate that there’s an easy way to navigate to a new page on the stack and show a UI, all within a single function. Of course, I could have split it into multiple builder functions if needed.

View the code on Gist.

To register an event callback for the onTap, I’d tried finding a Widget that exposed it directly. I’m accustomed to elements having events (often bubbling events) that would have exposed something like onTap. However, with the exception of specialized widgets like Buttons for example, it’s not exposed on most Widgets (even those that have UI). So, at the outer layer of the items being shown in the ListView, I used a GestureDetector to capture the tap event:

View the code on Gist.

I would have preferred that the Container to have the event available. Maybe it’s not as pure, but, meh. I’d like to reduce the noise of building a UI and adding yet another layer just to capture an event is a distraction.

Architectural elegance does not always lead to a framework that is easy or friendly.

While I wasn’t really concerned about performance of my application or the possible impact from hitting the BoardGameGeek API a few times, I used application storage to cache a copy of the XML data that’s retrieved from BoardGameGeek just to get some experience with the APIs. Further, I added code to store the next time the file can be updated to the SharedPreferences object instance (to prevent it from being updated too frequently). I liked the simple exception handling in Dart as it’s relatively low impact to handle a specific exception type without caring about the details by using the on clause (just by dropping the catch(e)).

View the code on Gist.

I noticed that the exception handler can specify one or two parameters. The first is always the exception and the second is the stack trace (StackTrace).  I’m not sure why the stack trace isn’t part of the exception object though.

When the file is cached completely and successfully, the Widget state is updated, which triggers an application refresh, which is what happens on lines 29-32.

Had Flutter been an option in the earlier days of Android, it would have been a strong contender in the application building space, especially that it runs on Android and iOS. From reading some of the issues on Github, the general consensus is that the cross-platform Flutter competitor to beat is React Native. In fact, I’m surprised that it has taken Google this long to produce a potentially viable alternative to the Java Android development tools. I’d honestly thought they’d announce something several years ago (I’ve watched Google I/O for many years for the announcement).

If Android devices were upgraded more routinely (as are iOS devices), web technologies such as installed progressive web applications could be a serious contender and alternative for many application types. But, modern Android operating system versions are very slow to roll out (if ever) to the majority of devices.  Over half of Android devices are running Android 6.0 or earlier.

Until the Android OEM ecosystem delivers timely updates to all phones newer than 5 years, solutions like Flutter (and competitors) remain a potentially reasonable way to reach a large variety of devices without needing to update to recent OS releases. However, it may be that the hardware hosting older versions, such as 6.0/Marshmallow and earlier are not capable of adequately executing a modern app built with technology like is used by Flutter.

Continued concerns

I still find the syntax of building a UI to be cumbersome and frustrating for several reasons:

1. Using code to describe the UI is not effective for me. I can’t as quickly look at a block of code and determine what the UI is likely to be. It’s just too noisy.
2. I’m constantly frustrated by getting the right number of closing parentheses to match the open parentheses. Using the auto formatting tools of Android Studio for Dart doesn’t make it easier. There are 10 lines that are marking the closing of some block. I’ll add an example below of how messy it starts to look if they’re combined in a way that the auto formatter suggests.
3. In fact, if it were easy, I’d want to lines to start with the Widget type rather than child: new WidgetName(. But, there’s not an obvious way to format the code that way as the named parameters (child) are needed to provide the widget instance.
4. Layout is a mess of classes and initialization. The examples on the web site make general sense, but when I’ve tried to innovate on my own and understand how to build other UI patterns, I’ve struggled to find the right combination of Widget classes that represent a desired layout. I imagine that with practice I’d get better, but I also would likely create multiple stateless Widgets to make some of the common patterns I’d expect to use routinely.

Does Flutter have a future? Would you want to build an app that you wanted to still be building on 3-4 years from now? As it’s still in Alpha form, I wouldn’t do anything but explore.

Then, there’s Dart. The strength of many development options for mobile and web development is the ability to concentrate on one programming language and have it work on client and server. With Flutter and Dart, if you don’t have a serverless-style architecture in place, you’ll need to use a second programming language. And that may limit its adoption. Of course, developers that work on multiple app platforms today have accepted this is just the price they have to pay, so maybe that’s not a big deal. If you’ve got a development shop that can have developers specialize, then this may be a non-issue entirely. For startups and very small teams, it’s a potential obstacle that must be considered.

Notes

If you try the code as I’ve put it on GitHub, you may encounter an error with a codec. This is actually a bug in the Flutter framework and apparently is fixed already and will be available generally at some point in a mainline branch. You’ll just need to rerun it.

Example of Auto Formatting

Note the parentheses on lines 20 and 21. That style causes me to just keep adding closing parentheses until the syntax is correct or the error is different. They’re very difficult to count.

View the code on Gist.

Android Studio

Android Studio is an acquired taste from a theme and style perspective. With a few adjustments, it’s tolerable.

I’m not sure why Keywords in the Darcula theme are bright, bolded orange. While keywords are important, they’re unnecessarily vibrant, especially in code blocks describing the UI:

I turned off the bold minimally and changed the color of class names as an experiment … it’s better, but not right yet.

It uses the programming language Dart. I’d looked at a lot of Dart code when it was first announced, but hadn’t looked at it much since. I couldn’t see it gaining meaningful traction against the JavaScript juggernaut as a transpiled option (as it added too much overhead from the complaints I’d read) and there was zero evidence that any company besides Google was considering integrating it as a native option for Web pages. Without broad industry cross-browser support (from desktop to mobile as well), it seemed like a dead-end option that didn’t add measurable value. In some ways it was doomed to fail as it was trying to be a better JavaScript rather than rethinking the whole client development experience. It was just a new web programming language.

Originally, Dart’s messaging was broad and suggested that it was an ideal language for everywhere. That has changed since it’s original announcements to be focused on client development. But, that shift was recent and apparently connected with the announcement of Flutter.

From November 1, 2011:

to late February 2018:

Even as recent as May 2017, the Dart team was still considering server development as a potential platform target:

It seems logical that the team would pivot to concentrate on a single target platform type, the “client.” Dart hadn’t gained substantial traction in server development or client development. While a recent video I’d watched suggested there were 70 million lines of Dart code on Github, I’m not sure who’s writing all that code and why. The dart-lang repository hosted on GitHub hasn’t seen a lot of “Star” love.

Compare those numbers to TypeScript for example:
Nearly 30,000 more stars (and TypeScript was announced about a year after Dart).

I wouldn’t choose Dart for new development outside of Flutter. My initial impression is disappointment that the Flutter team is using Dart as it adds one more language to the client-side development smörgåsbord. I don’t know that the world needs another programming/UI toolkit lock-in option right now added to the buffet. I like variety and competition, so I’m all for that, but I also worry that limited adoption of frameworks leads to abandonment and frustrated developers. I can speculate why they choose Dart, especially as it’s staffed by Google developers, and I can see the appeal of the language, but….

I don’t need more programming languages right now in my solutions toolbox. It’s one more thing to learn and master. Since Flutter is also new, it has made the initial ramp-up time longer than I’d expected and wanted.  And because the language syntax is very familiar by design, it’s unfortunately likely that habits from other C-like and TypeScript-like will find their way into coding I do in Dart.

While the community at large apparently considers the Widget building syntax to be a strength of Flutter, I can’t say that I’m excited about it. It’s chatty and verbose. (And I haven’t been able to tell if the enthusiasm about the current syntax is just from the early adopters or fans, or it’s generally well liked). It absolutely doesn’t feel like it’s moving the needle when compared to all of the other GUI frameworks that have come before it. In fact, it reminds me of my earliest coding experiences using Turbo Vision. Yeah. Turbo Vision from Borland. (Wow — the past 20 years of IDEs and development tools originally from Borland has undergone an amazing number of ownership changes).

(Yes, it’s not really like that too much, but I had some flashbacks to my Turbo Pascal days).

Here’s a snippet of some code, written in Dart which represents a single item (more about this in a later post), with a thumbnail, a name, and a year published.

View the code on Gist.

Of course, alternatives have been proposed, like a JSX-like syntax. This proposal brought out the best and worst of engineers of course. A few of the collaborators on Flutter were so dismissive of the idea I nearly stopped looking at Flutter.  As Flutter is in its early days, and backed by Google, I expect ideas are rationally considered and individuals to be treated with respect, even if there is disagreement. I’ve done years of WPF, Silverlight, and UWP development which used XAML. While there continue to be some rough spots in XAML, I appreciated the structured document for building a UI. I don’t know that I’d go in that direction for Flutter, but I don’t think describing complex user interfaces entirely in code is the best for its future viability, especially as it needs to compete with a variety of other frameworks and options.

Ignoring the syntax of how to describe a UI though for a moment, I’m still having trouble with wrapping my head around the idea that State actually renders a UI:

View the code on Gist.

It’s the build method that returns the object hierarchy that describes the widget tree, not the class that subclasses StatefulWidget.  If you instead use a StatelessWidget, it builds its Widget hierarchy directly within the class. I can see how they arrived at this implementation, but it just feels inconsistent.

I like the async/await support in Dart. I do wish that I wouldn’t need to specifically declare the return type as Future<T>. The code has already signaled that it’s async, so if Future<T> could just be T, some code clutter would be eliminated.

View the code on Gist.

The the code above, it’s great that the return value is automatically wrapped in a Future without any special code, but taking it a bit further would make Dart and Flutter more appealing.

I’ve been using TypeScript long enough that let and const functionality is second-nature. Unfortunately, Dart’s language is subtly different and I end up trying to use const where I meant to use final. That’s my problem of course, but it’s just a gotcha. Const in Dart is for compile-time constants.

I’ve been generally pleased with using Android Studio with the Flutter plugin. It performs reasonably well, and it’s a good editor with lots of bells and whistles. The build/debug times are quite long, even for a basic app. It’s about 25-30 seconds for a build and deploy to an emulator. Thankfully, the plugin and Flutter both support hot reloading, so many changes to the code can be updated without needing to do a new build/deploy. While that’s very helpful, I’d like to see a significantly reduced build and deploy time.

In a market saturated with options for building cross-platform application UIs, it’s not clear how Flutter fits in. I’ve liked the experience enough that I’m going to build out a few simple apps and will show off more details in a later post of an app I’ve been tinkering with as I learn the platform and development environment. Flutter is in an “alpha” state right now, so a lot could change before it’s available in a final release (if it ever is). According to their Github repository, they have currently 86 issues open for their “beta” milestone. There’s no meaningful date associated with the transition though.

The essential pieces:

1. Call WithTimeout passing the Background() context and specify the timeout (I’ve specified  3.2 seconds)
2. Be a good citizen and defer the cancellation (to be sure that it’s called) and defer close the channel
3. Start the go routine which waits for the Done channel
4. When the Done is signaled, display the current time in seconds and what caused the signal
5. The main app is waiting for the goroutine to end, so signal that.
6. In the main function, the code sleeps and wakes emitting some time stamps to the console
7. Depending on whether cancel is called, the goroutine signal may be one of two things.
   1. If cancel is not called prior to the second sleep in the code, the ctx.Err() returns

      <-ctx.Done():  context deadline exceeded

   2. If cancel however is called, the ctx.Err() returns:

      <-ctx.Done():  context canceled

8. Then, the goroutine uses the channel to signal completion (wait<-true).

View the code on Gist.

You can experiment with this sample here.

With cancel called (the line cancel() not commented out):

first sleep completed,  02.00
Timeout: 02.00
in <-ctx.Done():  context canceled
after second sleep done,  04.00

And, with // cancel() commented out:

first sleep completed,  02.00
Timeout: 03.20
in <-ctx.Done():  context deadline exceeded
after second sleep done,  04.00

Hopefully this helps someone besides me.

To make the connection more automatic, I created a simple one line PowerShell script that periodically attempts to connect to any disconnected iSCSI targets using the Windows Task Scheduler.

I saved this into a script file called reconnect-iscsi-targets.ps1:

Get-IscsiTarget | where ($_.isConnected -eq $false) | Connect-IscsiTarget

Then, in the Task Scheduler, I created a new task set to run every 10 minutes daily. The script just gets all iSCSI targets, filters only those that aren’t connected, and then passes the results to the connection cmdlet.

For the action, I selected “Start a program” for program/script, I entered: “powershell.exe”, and then added the arguments “-File” and the full path to the file name, like:

-File c:\Users\aaron\Documents\reconnect-iscsi-targets.ps1

If there are spaces in the path to the PowerShell file, be sure to add quotes around the full path and file name.

You shouldn’t need the start in option set (leave it empty if you’d like).

On the General tab of the task, make sure you’ve set the “Run whether user is logged on or not” option and “Run with highest privileges.”

Next up — how to quickly create a Self-Signed Code-Signing certificate. And, how to actually allow scripts to run!

I could finally explore the magic of this new document-based database (I can’t say “NoSQL” as it supports a SQL dialect) without spending money just to explore the database (it was a “pay to play”).

However, it’s not to be for me:

1. Worst: It supports requests from LOCALHOST only. Its ports are bound to 127.0.0.1 rather than 0.0.0.0, thus preventing it from being usable from other machines. I wanted to install this on an always-on PC in our house rather than install it on my home workstation. I can sort of see why they want to limit it, but come-on, this is for development purposes. It’s not set up for availability, performance, etc. One simple right click of the app-tray icon resets and clears all the data. There are a number of effective ways for making it developer only — and I wouldn’t have picked this one.
2. It has constantly used CPU, even when it’s not being used. On my laptop for example, it was hovering around 10-15% CPU, even when there were zero active connections. This problem isn’t consistent as I installed it on a secondary workstation and it’s using a lot of RAM (nearly 400MB), but only 1% CPU.
3. It’s Windows only. This is actually a minor point if you’re using Windows, but if you want to use a Mac and do development, even with a VM hosted emulator, you won’t be able to.

So, for the best experience with DocumentDB, you’ll likely need to stick with the pay-to-play option of hosting it in Azure. I’m disappointed. I’ll look for a different database … something that doesn’t have this limitation.

Bummer.

On Linux, this is already available, but the the Windows version is lacking. I wanted a tiny console app that would display a tree of the directory and file structure.

So, that’s what I built.

It’s one small file with one external library dependency.

I did notice that the Go packages for directory scanning like ReadDir suffer from a common issue when using the traditional Win32 APIs: they do not adequately handle file paths longer than about 250 characters. When you have NodeJS source code on your system with lots of deeply nested paths, many Windows programs fail miserably when doing file/folder management operations (Windows Explorer, I’m looking at YOU). Using the one “easy” trick of prepending the path with \\?\, you can use the APIs like ReadDir reasonably reliably. Whereas in earlier versions of my tree app it would crash, it now can handle deeply nested directory structures.

go get github.com/fatih/color

View the code on Gist.

On Windows, using Visual Studio Code 1.7+, pressing SHIFT+CTRL+C opens a Windows Command prompt from the root directory of your opened folder. It’s super useful.

I wanted the Developer Command prompt to open instead of a standard command prompt.

To change that, open the User Settings:

Add the following:

"terminal.external.windowsExec": "C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\Tools\\VsDevCmd.bat"

Of course, you can use other batch or command files to customize the prompt. I just wanted all of the standard developer tools I have installed to be available.