A Small Rant About Being IDE-Dependent

{Sort of a Rant}

I recently saw this tweet.

I responded with this tweet.

Now I need to describe some context around this response real quick. Here are the key points behind this tweet from my context in the software development industry.

  1. I’m not a .NET Developer. I’m a software developer, or application programming, coder, hacker or more accurately I’m a solutions developer. I don’t tie myself to one stack. I’ve developed with C# & VB.NET with Visual Studio. I’ve done C++ and VB 4. I’ve done VBA and all sorts of other things in the Microsoft space on Windows and for the web with Windows technology. About 5 years ago I completely dropped that operating system dependency and have been free of it for those 5 years. I doubt I ever want to couple an application up to that monstrous operating system again, it is far to limiting and has no significant selling point anymore.
  2. In addition to the .NET code I’ve written over the years I’ve also built a few dozen Erlang Applications (wish I’d known about Elixir at the time), built a ton of Node.js based API and web applications, and have even done some Ruby on Rails and Sinatra. These languages and tooling stacks really introduced me to reality I longed for. A clean, fast, understandable reality. A reality with configuration files that are readable and convention that gives me real power to get things done and move on to the next business need. These stacks gave me the ability to focus more on code and business and research value and less on building the tool stack up just to get one single deployment out the door. Since, I’ve not looked back, because the heavy handed stacks of legacy Java, .NET, and related things have only laid heavily on small business and startups trying to add business value. In the lands I live in, that is San Francisco to Vancouver BC and the cities in between, Java and .NET can generally take a hike. Because businesses have things to do, namely make money or commit to getting research done and not piddling around building a tool stack up.

So how was this new reality created? It isn’t a new one, really the new reality was this heavy handed IDE universe of fat editors that baby a developer through every step. They create laziness in thinking and do NOT encourage a lean, efficient, simple way to get an application built and running. It doesn’t have to be this way. A small amount of developer discipline, or dare I say craftsmanship, and most of these fat IDEs and tightly coupled projects with massive XML files for configuration in their unreadable catastrophofuck of spaghetti can just go away.

Atom, Sublime, and other editors before that harnessed this clean, lean, and fast approach to software development. A Node.js Project only needs one file and one command to start a project.

npm init

A Ruby on Rails Project is about the same.

rails new path/to/your/new/application

That’s it, and BOOM you’ve got an application project base to start from.

Beyond that however, using a tool like Yeoman opens up a very Unix style way of doing something. Yeoman has a purpose, to build scaffolding for applications. That is its job and it does that job well. It has a pluggable architecture to enable you to build all sorts of scaffold packaging that you want. Hell, you can even create projects with the bloated and unreadable XML blight that pervades many project types out there from enterprisey platforms.

Take a look at Yeoman, it is well worth a look. This is a tool that allows us to keep our tooling, what we do use, loosely coupled so we don’t have a massive bloated (5+ GB) installation of nonsense to put on our machines. Anybody on any platform can load up Yeoman, and grab an editor like Atom, Submlime, Visual Studio Code (not to be confused with the bloated Visual Studio) and just start coding!

Take a look at some of the generators that yeoman will build projects for you with -> http://yeoman.io/generators/ There are over 1500! No more need to tightly couple this into an IDE. Just provide a yeoman plugin in your editor of choice. Boom, all the features you need without the tight coupling in editor! Win, win, win, win, and win!

As a bit more of my rant about bloated editors, and don’t get me wrong, I love some of the features of the largesse of some like Visual Studio and WebStorm. But one huge rant I have is the absolutely zero motivation or vested interest that a community has to add features, bug fix, or do anything in relation to editors like Visual Studio or WebStorm. ZERO reason to help, only to file complaints or maybe file a bug complaint. That’s cool, I’m glad that the editors exist but this model isn’t the future. It’s slowly dying and having tightly coupled, slow, massively bloated editors isn’t going to be sustainable. They don’t adapt to new stacks, languages, or even existing ones.

Meanwhile, Atom, Sublime, and even Visual Studio Code and other lean editors have plugin and various adaptar patterns that allow one to add support for new languages, stacks, frameworks, and related tooling and not have tight coupling to that thing. This gives these editors the ability to add features and capabilities for stacks at a dramatically faster rate than the traditional fat IDEs.

This is the same idea toward tooling that is used in patterns that a software developer ought to know. Think of patterns like seperation of concerns and loose coupling, don’t tie yourself into an untenable and frustrating toolchain. Keep it loosely coupled and I promise, your life will get easier and that evening beer will come a little bit sooner.

{Sort of a Rant::End}

…and this is why I say, do NOT tie project creation into an editor. Instead keep things loosely coupled and let’s move into the future.

Xamarin and I Are Hella Busy Hacking This Week

This week, along with the normal duties of getting everything from SSL working to code slung for account management to intellectual property (what is that exactly 😮 )…  this week is going to get hella busy. Here’s a few of the public events and training that I’ll be attending this week along with the normal bike n’ hacking n’ gettin’ shit done.

Shared Code Projects, PCL and Xamarin on 7/8/14 @

Intel JFCC Auditorium
2111 N.E. 25th Ave
Hillsboro, OR

James Montemagno  from Xamarin is coming to learn us the deets on how to create common core code that can run on any or all common platforms. Find out the differences between shared code project, portable class libraries, and simple file linking to share more code on iOS, Android, and Windows. This should be pretty kick ass to help kick OrchestrateExecutive off the ground. There’s a little more info here for the event: http://www.padnug.org/.

Database Stuff that aint RDBMS on 7/10/14 @

I’ll @adron be presenting on database types, what’s available out there outside of the relational and RDBMS world. How to resolve various problems with alternate data solutions for better results, better performance and ways to leap around the hurdles that are sometimes faced with RDBMS use.  More info here: http://www.meetup.com/ssdevelopers/events/176032122/

Xamarin Hands-on-Lab/Hackathon on 7/12/14 @

Montgomery Park

Kelly White @mckhendry has put together a hands-on-lab and hackathon, just a few days later hosting a hand-on-lab working with Xamarin to build apps. I’m going to hit up this event too (then go ride a 100+ kilometer bike ride, anybody up for the ride, ping me?) and sling some code on OrchestrateExecutive. Also a little more info here for the event: http://www.padnug.org/.

There’s more, but these are the top few meets I’ll be attending over the next two weeks. Happy hacking!

Getting Started with Swift, For NON-Apple Devs

This past weekend I attempted to get started with Swift coding. Since I have not been an Apple Developer for a while, it wasn’t immediately obvious how to get started. But once I fumbled around a few minutes I realized I needed a developer account to get the latest XCode. Jeez, it really shows how much Apple loves to lock you in hard core to their development ecosystem. An unfortunate trait of a company that is actually extremely closed in much of its behavior, while taking advantage of so much of the open source community. But I digress, this isn’t a rant about the unethical behavior of Apple. I’ll reserve that for the novels worth of material it deserves.

One I signed up for the developer program, which costs $99 bucks, I immediately made my first huge mistake. This damnable mistake blew the entire weekend of hacking. I added under “Company” my simple DBA (Doing Business As) name. I already had an account, and because of this change for making this existing account become a developer account from a personal base level account, sprung a red flag. I checked back frequently over the weekend, but it wasn’t until Monday that somebody checked the app, realized the Company name I added was merely a DBA and ok’d my account. So far, 38 hours down the drain for getting started hacking on Swift! Dammit.

However, this morning I was happy to find everything was ok’d, and thus, the remaining bit of this blog entry is a bit more example and a little less story of my day.

Developer @ Apple

Developer @ Apple

Getting XCode 6 beta

I wanted to do Swift hacking, the first step was to download XCode 6 beta. That’s available via download on the iOS Developer page (and I suppose the Mac Developer page). Scroll down on that page until you find the XCode Download button.

The Warnings and the Download XCode 6 beta page.

The Warnings and the Download XCode 6 beta page.

Also note, if you’re looking to do Swift hacking like I’m doing here, I’d actually advise against getting the iOS 8 beta or OS-X Yosemite Developer Previews right now. Best to keep as stable a machine while toying around with a new language. At least, that’s what the conversations have been so far…

OS-X Yosemite & iOS 8

OS-X Yosemite & iOS 8

Once I got Xcode 6 beta installed I dove right into creating a Swift Project. I created a simple new project that is empty to just check out what Xcode 6 provides out of box for the Swift Project.

Selecting an empty Xcode 6 beta project to use with Swift.

Selecting an empty Xcode 6 beta project to use with Swift.

The next dialog is where the Swift magic is selected.

Selecting Swift, entering a project name and other information dialog.

Selecting Swift, entering a project name and other information dialog.

After that I just clicked through on defaults until I got into the Xcode IDE with the project open.

Selecting the appropriate simulator.

Selecting the appropriate simulator.

Next I executed the project. Since I’d had my phone attached it wanted to run it there, but I have 7.1 iOS on it which won’t execute Swift code. I had to select the appropriate simulator then to run the application project. Once that ran, since I’d not done so on this particular computer, I needed to enable developer mode.

Enabling developer mode.

Enabling developer mode.

I did so and the empty application launched.

An empty iOS 8 iPad Retina Application.

An empty iOS 8 iPad Retina Application.

So that’s the basic getting started, no code actually slung. But rest assured I’ll have another post soon detailing some first code snippets. I also hope to get some comparisons written up between XCode with Swift and Xamarin Studio and C#. It’s cool that Apple finally has a modern feature rich language, so it’ll be interesting to see how each stacks up from a language and IDE perspective.

References: