posted under category: dotnet on November 14, 2017 by Nathan
I'm working, nearly full time, on a Windows 10 UWP application these days. Strange, right? How many people do you know who are doing that? I bet it's not many.
Historically, my company has been a pretty strong Microsoft shop. That, plus we didn't have a true mobile strategy, left us with Windows 8/10, but on smaller devices, so it's mobile.
Oh! Mobility. Why can't we just make a web app? Let me back up.
The fuselage of the Dreamliner 787 is pure carbon fiber. It's an amazing machine, built like no other. We create, all the way from carbon threads, a huge airplane with a handful of seams instead of the traditional aluminum plates all over. Carbon fiber doesn't give way as easily to fatigue, so they say a 787 airplane we make today could fly for the next hundred years and beyond (as if the design wouldn't be technologically outpaced far sooner). Another neat trait is that carbon fiber blocks more solar ionizing radiation than aluminum airplanes, making it safer for frequent flyers and crew members. The downside is that it also blocks other radio signals very well thanks to its otherwise awesome density.
So when we send someone into one of these beautiful airplanes to do some work, there's no WiFi, most likely no 4G, and sometimes we actually need software to work while the airplane is flying (shocking, I know). Applications on our mobile devices need to be able to be offline - occasionally connected. Throughout IT history, we've found that it's easier to force a signal or make a longer wire, but we have a unique case here.
HTML5 has great offline support. Some of the things you can do are quite astounding in an offline mode, but browser limits tend to get in the way. Specifically, the limits of offline storage mean there are only so many pictures we can take and data we can collect in our mobile apps before forcing a connection. Last I checked, most browsers top out at 20 MB. Also, the Media APIs and various offline and client-side data storage mechanisms are still not stable enough or cross-platform enough to be viable enterprise solutions. Plus, internet explorer is still a thing. Ug!
So we're building a UWP app, and it's the right choice.
Googling it, however, you won't find many people doing the same. There are plenty of stackoverflow questions about WPF and XAML, but those are most all from the pre-Universal Platform days.
There are a few frameworks out there, and the Windows store has a slowly growing number of apps. It's not really that no one is doing UWP, it's really just that's it's a small community with a quieter online presence.
Maybe the Universal world is still just growing. The technology is fairly new so not everyone is on board yet. Then again, maybe the platform is far too immature to choose. We are finding out the hard way that the cutting edge tends to break skin now and then.
Recently, I found that MSTest is completely broken in Visual Studio 2017. How is anyone going to test their code if the first party framework is a non-starter? The runner up is xUnit, which works but only runs in a UWP application window. Both of those choices have the major downside of not working headlessly - they can only run from a Windows 10 PC and will not work on an integrated build server of any type because they both need a window to pop up.
We've also had debugging problems since the beginning. You can hit F12 to follow a reference out of a XAML file, but you'll never be able to follow a reference into XAML. Also you lose app insights as you get closer to the UI. Then there are the false-positive errors any time a XAML file is open, where VS is convinced that something is broken in your code while it's actually perfectly valid.
So is it a chicken or an egg? Do these problems get fixed when more folks work with UWP, or is the world waiting for some of the major holes to get fixed before jumping on the wagon? Maybe it's neither and we should all stay away. Maybe it's both and it will never start.
Most likely it will take Microsoft 5-10 years to get it right, but by then, the next big platform will come out, full of bugs.
posted under category: dotnet on August 28, 2017 by Nathan
I like to be the smartest person in a room. I've perfected my expertise in CF development over the past 19 years, and I'm really good at it, but with technology marching on, I've found myself switching to C# .NET and Windows UWP app development. To say the least, things are different!
This is going to be sort of stream-of-consciousness, free-flowing thought. Brace yourself.
ColdFusion does a lot of things for you that just don't happen easily in .NET. CFSpreadsheet, for one, is something that's not accounted for at all, and a real detriment to my bottom line as far as getting things done for my customers. CFDocument and CFPDF are likewise completely absent, as is our beloved CFSearch. Many other things made simple in ColdFusion are just much more complex and require a lot more code and understanding in .NET, like caching, sending email, ORM, web services, and much more.
Everything in Dot Net land has a nearly-catchy name, and frankly, that's frustrating when you don't know what all their names mean. Entity is the ORM, fine, but Kestrel the web server is odd. Then there's the barrage of web frameworks: ASP.NET WebForms, ASP.NET MVC, the Razor template engine, ASP.NET Web Pages, and Razor Pages. Then the desktop family, WinForms, XAML, WPF, and UWP. That scratches the surface, but barely. Maybe my challenge is because many of the names are so similar, like .NET Framework vs .NET Core.
It's not even the object-oriented design that makes things difficult, either. While many of my CF colleagues are happy with procedural web applications, I've had my hands full with OOP in ColdFusion for 15 years, but I was pretty strictly modeling business domain objects and MVC pattern objects, whereas in .NET, I have a lot more low-level objects just to accomplish many of the same goals.
The C# language really is first class. It's been designed very well. Some of the more advanced features are still beyond me. There are a lot of things I can read, but not yet write, much like my Spanish skills. Have you ever tried reading a magazine or newspaper written in Spanish? Oh, I highly recommend it just to get some practice in language parsing. Thanks to our Latin roots, it isn't too hard to work through some, until you came to a word that just doesn't match, like "gatos." Is this article about alligators? No, it's about cats. It just takes time to learn all the specifics before you really understand what's going on.
PascalCase has been an annoying adjustment, but it's well thought out and the style guide is pretty clear. On the other hand, naming things on this new platform is especially hard. Is it a gateway or a repository? Everybody keeps trying to call things a "Helper", like the "SettingsHelper" in the Xaml Template 10 library, and I keep explaining to everyone in the office that a "helper" is not a type of object in an object-oriented system. Neither is a sender, receiver, or really most verbs or words that end in "-er." Some of this is my personal struggle with teaching programmers on my team and fighting against bad practices used in popular public frameworks, but much of it is really about coming up with the best name for a thing, because there are so many more things you have to code in C#.
Some of my difficulty is transferring out of my Java thinking into .NET thinking. I was never a big Java guy, and I never wrote anything more than a few sample apps and a couple utilities, but the Java language thinking is ingrained pretty deeply in my head. I'll get through most of it after a while, right?
I've had to completely re-learn debugging. Much of that is because of my incidental transition away from web development. There's so much more code in C# just to do the same thing, and so many things go wrong. Even with breakpoints, sometimes my app just skips from one operation to the exit and doesn't give me any hints as to why. Then I call over literally anyone for help and they find and solve my problem within 30 seconds. It's been humbling.
Something tricky to figure out has been the async/await syntax and how that works, how it cascades through an application, and thinking through the problems it can create when we don't always know if tasks are working concurrently. That's actually been a fun challenge, and I feel like it's a preview into ECMAScript 2017.
I'm not a fan of the way much of our interaction with the framework is through public static methods. This is both ineloquent, for instance in comparing java.io.File to System.IO.File, and also creates confusion with developers. In this case, Java's File is something you instantiate with a path, and .Net's File is static methods you call with a path. Is a File an object, or a string path to the object? Are we supposed to design our APIs with public static methods and classes, or as composable objects? I'm internally conflicted on the whole thing, and I keep going back and forth on designs in my head.
And then there's MVVM. Oh boy, that's going to be a topic for another day.
There's a lot more to it, and I have more to say, so stay tuned.
posted under category: dotnet on August 18, 2017 by Nathan
Adobe's server technology has paid my bills since then. I've also blogged and tweeted and spoken at conferences, written open source and have been a good community member. You could say I've been a fan.
Still, no one can be a one trick pony in today's world. As chance would have it, my language of choice after CFML (and JS, so, I guess 3rd language) has always been C#. Here's a little story about how that happened.
First though, I have a lot of ColdFusion community members to thank for teaching and encouraging the rest of us the fundamentals of object-oriented programming. Thanks to all of you who spoke, blogged, emailed, and tweeted over the years! Without you, I would have been far less.
In 2002, I worked at a little startup in Arizona building targeted dating sites. The code I inherited was, let's just say, typed very quickly, maybe without thinking first. One Friday afternoon, the CEO rushed in and announced that ColdFusion is dead and we needed to rewrite all the sites. .Net was too new for him, so he decided classic ASP was definitely the best way forward. With protest, I bought a couple books and read them over the weekend so I could hit the ground running on Monday. Progress was slow and, honestly, the platform was awful! ASP with VBScript is a platform built by computer scientists, not web developers.
The next year, our CEO wanted a desktop alert app that would enable persistent connections to our dating sites so you can know the exact moment that someone likes your profile. We decided to build it in C#, which was still a little risky at the time for a widely deployed application. I used my knowledge of OOP to design and build some of the back-end and server communication libraries. That was my first real taste of C#.
C# became my hobby language. When I wanted a desktop util or a little toy, I built it in C#. For fun, I built a little WinForms app that let my wife upload photos to our web site - drag & drop, automatic resizing, write a caption and you're done! This was years before Facebook essentially took over the old family web site thing. I still use an app I wrote to correct certain file names, and another one to empty the temp folders on my hard drive. Sometimes I put a little thing together to parse big XML files or resize photos. You know, hobby stuff.
Years later at a different company, I had the task of speeding up our ColdFusion job that downloaded, cropped, and created the thumbnails of thousands of hotel photos for a reservation site. After exhausting all of our CF options, I decided to try it in C#. Instantly it cut a 12 hour job into 2 hours with better looking photos, then I used multithreading to cut it down to 20 minutes. I was hooked, even though ColdFusion still paid the bills.
My CF skills brought me to Boeing as I took over a very well designed OO application. Since then, I've had very few chances to do anything outside of ColdFusion until this year.
Earlier this year, my manager handed a group of us a UWP app. Yep let's just put the web developers into the desktop world! And that's that. I've jumped in with both feet, and I think I'm doing pretty well.
I'll have a lot more to talk about on this subject, coming as soon as I can type it.
posted under category: dotnet on April 20, 2006 by Nathan
Microsoft's Visual Studio Express editions are now free forever. Previously, they were free for a year.
Apparently, Microsoft is going after the amateur developer community. This is good news on a couple levels for us. First, because SQL Server Express is a great tool, and can be deployed on a site for free. I'm having trouble finding the license or limitations for it, but it's my understanding that it has a 4GB size limit and a 1 CPU usage limit, and is missing a couple other features. Otherwise, it's still SQL Server 2005, which is pretty popular with the CF community. - BTW, they also just launched a lighter and free-er version of their SQL manager tools.
The second great reason, something I've been a proponent of, is it's a great opportunity to learn a new programming language, and a new web application framework and structure. I say this over and over, but I really mean it. It was learning VBScript (with ASP classic) that transformed me from an ok CF coder into a great CF coder (btw - I came from the HTML jockey side, so CF was an obviously perfect choice for me).
Anyways, I'm not advocating ditching CF for .NET. It's really not worth it. But it is cool to be able to write a couple desktop apps here and there, and learning more puts more tools in your toolbox.
posted under category: dotnet on December 25, 2005 by Nathan
So, happy holidays all. Given a little extra time this morning, waiting for the in-laws to come back from shopping, I felt the need to rename some files. Ok, a lot of files. All of us CF guys can attest to the ease of getting it done in our favorite tag-based language, but what about running it without having to start 3 services on my local machine? That's where knowing a 2nd language fits in.
So, with an effort to (a) play with visual studio 2005, (b) test drive .NET 2.0, and (c) actually make something useful, I present to you the Regex Mass File Renamer. Install the .NET 2.0 runtime, it came out a couple months ago, download my app, and run the exe in the build folder.
It's not fancy, it's not all that great, but it's what I do in my spare time to make life just a little easier for myself. Choose a folder, enter a regular expression in the 2nd box, and something to replace it with in the 3rd, then hit start and it will change the filename (sans extension) of any files in the chosen folder.
The zip file is my whole project folder from VS2005, so if you have Visual Studio '05, even the free (for a year) express version, you can open the project and play with the source.
Disclaimer: I won't claim to be any sort of OOP expert or great winforms programmer. The code may suck beyond belief. In fact, I'd like to know if it does. Use at your own risk. Make a backup of any files you plan on working with. The source is provided so that I cannot be held responsible with how the program works, or for anything that happens when running it.
posted under category: dotnet on June 23, 2005 by Nathan
I just noticed on OSNews an article on Builder.com about how to get into .NET development without the costly overhead of a Visual Studio license or MSDN subscription.
In my c# development (my latest toy language -- oh, i've got a new project ;) I use Visual Studio. Yep it's good and stuff, but it does fall short in a lot of areas, like it's about 1.5 GB with the library files, which, I guess provides help. I don't know, it's never been that helpful. You can't have files from 2 projects open at once, there's no tag insight for ASP.NET or HTML (or css or...) pages, the interface, while customizable, just can't stand up to Eclipse, and neither can the 3rd party tools, plugins, etc.
So yes, I use it, as it's free to me (with my employment, so it's kinda like they pay me to use expensive software), and it works fine. There are positives too, like, it's fast and always seems to work.
For starters doing dotnet, find and install the SDK. The documentation app that comes with it has been more than worth it's weight in megabytes for me.
If you want to write a windows desktop application and you don't want to fork the cash or install for 6 hours, get SharpDevelop. I've used it and it's cool. Easy to run, a lot like VS.NET where it starts with a visual 'WinForms' designer and you drill down into the code view to do real programming.
If you ever thought of using Visual Studio to write ASP.NET pages (aka WebForms), get your head examined. "Oooh but they have the free Web Matrix tool" That's some serious crap software. Don't even download it. Your best bet is to develop your front-end in Dreamweaver. It's got a couple wizards and perfect content assistance for all your asp: tags.
Last up, if you want to do any c# in Eclipse, forget about it. The Improve C# Plugin really isn't that good, and I haven't seen anything else worthwhile.
posted under category: dotnet on May 23, 2005 by Nathan
My first, meaning non-test, non-sample-driven, not-from-a-book desktop app. I'm writing a photo uploader for my "our family" section, which, thanks to some oh-so-clever recursive direcory deleting programming of mine, got tragically wiped out (curses!).
I'm writing it in c#, which is actually a lot of fun. Never having made a desktop application, or a .NET project at all, it's really not too hard. I mean, it's not walk in the CF park, but it's relatively simple when you get ahold of the MS programming model and figure out their own dictionary.
I'll put up a couple screenshots and post the code when I've got it in a good working state, granted it's not going to be the most impressive thing you've seen, but it could spark some ideas for 'smart clients' - it's already doing that for me.