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.
(Discuss with Disqus!)
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.
This isn't to say that everything on the .NET platform is bad. Quite the contrary. I am having a lot of fun enjoying a wider world of programming! I feel like it's both burning me out and giving me a reason to go on even harder. The ability to run a compiler and pop out an exe file is fun. Using properties instead of accessors & mutators (get & set) is nice, though that one is available in modern CFML. I like how .NET runs a good amount faster than Adobe's CF. I also feel like I really understand the draw toward statically typed languages, though I can't say that I prefer it yet, given the magical world of JavaScript I dream about.
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.
(Discuss with Disqus!)
posted under category: dotnet on August 18, 2017 by Nathan
I've been making web sites professionally for over 20 years, an aeon on the Internet. I was a full stack lead developer when Netscape sold the first JavaScript server to Sun, and I'm not even 40! I've been programming ColdFusion since '98, still the dawn of web applications.
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.
(Discuss with Disqus!)
posted under category: General on February 14, 2017 by Nathan
You want to travel to the Bahamas and you have to pick a web programming platform to take you there.
ColdFusion is a cruise ship with almost no other passengers. It's all inclusive. It's a smooth ride, but sometimes it docs 50 feet from the port and you have to swim the rest or book the last bit with Java.
Java is a full cargo ship. It's slow to get moving. You have a very safe room in the center of the boat but you have to catch any cargo containers if they fall on you. You'll get to Nassau, eventually, and it's safe because there are a lot of boats here in these shipping lanes.
ASP.NET WebForms is a yacht that drives backwards and only responds to events like when you run into a dolphin.
ASP.NET Web Pages is a very small yacht that tows the ASP.NET MVC yacht where all the parties are thrown.
ASP.NET MVC is a yacht with an iron hull. It sits heavy in the water, but it can clip along at a good pace and there are nice rooms. Many parts are actually designed well, and it should because it cost you a pretty penny.
Go is a navy destroyer. It's much faster than the published speed, but not very comfortable. Unfortunately, you only wanted to go on vacation. As you get on board, you unintentionally sign with the navy. You can't stop talking about how much you love it all.
PHP is a tug boat with tires tied to the outside. Why would you go to the Bahamas in a tug boat? It can get you there, but where is the bathroom? Everyone except Ruby is passing you and it seems like they're all having a better time.
Ruby is a beautiful steam-powered riverboat with a huge rotating paddle in back. Nothing matches its charm and luxury, but it's going to take you forever to cross the ocean in this, and it might just break on the waves. You hope for good weather and set out before finishing any seaworthyness work because it's already floating.
Python with Django is a sailboat with big white sails. If you know what you're doing, and you trim your whitespace sail in the correct position, you can get moving very quickly.
Python with Flask is a windsurfing board. It's basically a sailboat, but it's very basic. Extend it with a surfing kite to head out across the ocean.
Node.js is 370,799 tiny interconnected boats that let you walk to the bahamas. Only one person can move at a time. (Note, the NPM repository at this time has exactly 370,799 packages in it.)
CGI with C++ is an ocean row boat. It's a lot of effort but you're definitely going to get there, so long as you don't give up.
C is a life raft, deployed a few miles off of Miami. Good luck.
Assembly is a stick. You hold it over the water, hopefully the ocean will part. It's an older way of sea travel, granted, but if you know what you're doing, and you pointed it the right way, you can drive a ferrari to Nassau. Also, you question if anyone's really done this.
(Discuss with Disqus!)
posted under category: ColdFusion on January 13, 2017 by Nathan
Many of you know me and where I work. If not, let's just say it's a big place with lots of smart people who all have their own motivations that generally align with making money. Over the past couple decades, we've had an increasing number of ColdFusion applications, mostly on the company intranet. At this point we have literally thousands of CF sites and apps, developed by hundreds of skilled and unskilled ColdFusion developers. We also have a heavy investment into server architecture to support this. It's not been cheap or easy to get here.
Why, then, did we make the decision to leave ColdFusion?
Over the past few years, our Enterprise Architecture department has been trying to reduce the amount of variation in applications around the company. It makes sense because having a more homogenous server and application architecture can reduce costs. So what did they pick instead? The new application infrastructure is going to be nothing but Java, especialy with Spring MVC, and ASP.NET MVC. That's it. Nothing else.
We know from lots of experience that neither Java nor ASP.NET is actually a cheaper solution because of the cost of IDE software and other various servers and components to match the functionality in ColdFusion. Also, a Java developer has a more demanding salary than someone who does a little more than HTML, or an analyst who dabbles in dynamic web programming. Long story short: We're not doing it to save money.
Is it because ColdFusion is last decade's technology? Well, what does ColdFusion do? It puts web sites on our intranet while connecting to every type of other system we may have running. Okay, it's not tablet apps, but it can let you create mobile web apps. It stands as a sturdy back-end to JavaScript applications. This is not old technology, not by a long shot.
Are we dumping ColdFusion because of a rapidly shrinking talent pool? Maybe. It's hard to say because we haven't been hiring a lot of people over the past few years. However, if you've ever seen ColdFusion, you know it's essentially HTML-plus. CF's unbelievably low barrier to entry means anyone with HTML skills and 15 minutes of playing around can write CFML on their resume. Complex CF applications are something else, but are generally along the lines of any MVC application on another platform. Also, as I said, we already have hundreds of ColdFusion-literate people - we're not short for talent.
No, instead of all of this, we are moving away from ColdFusion because of Gartner's IT Market Clock for Programming Languages. I've read it - Gartner does a very strong analysis of the market as a whole from what information they can learn on the public internet. They check the job sites and question boards like StackOverflow, and they determined that ColdFusion is on the brink of obsolescence. In our proactivity, we are jumping off before it gets ugly.
So why are we moving away from ColdFusion? In a word: Gartner.
(Discuss with Disqus!)
