Some big news in the .NET/Microsoft world today: the .NET runtime (roughly equivalent to the JVM in the Java world) will now be fully open source (MIT License) and cross-platform. This means .NET will be fully supported on the Mac and Linux. It looks like the aims of Mono, the current community-driven cross-platform open source implementation of .NET, will now be fully realized as part of the core .NET platform. Mono is primarily leveraged for cross-platform mobile app development with the Xamarin ecosystem. Microsoft’s further partnership with Xamarin means that .NET is one of the most compelling mechanisms for cross-platform development today.
I’m excited to see Microsoft embrace open source. The effective patterns and practices that we’ve seen emerge and evolve in the open source ecosystem, regardless of platform, can be lost on individual enterprises or proprietary vendors. It’s great to see Microsoft seeing the value and effectiveness of these patterns and aligning their efforts with how developers work, not the other way round.
I’m also happy to see a desire on Microsoft to deliver the best solutions on any platform, not just the BYO-platform attitude that we started to see a year or two ago (which was still revolutionary for Microsoft).
Scott Hanselman just introduced support for front-end build tools grunt, gulp, bower, and npm on his blog. Visual Studio is going to have support for front-end build tooling and package management. As Scott mentions, there still is possible use cases for using NuGet to distribute front-end assets.
My advice to most freelancers early in their career: don’t do it long-term. There is a definite long-term limiting factor when it comes to freelancing that impacts your professional (craft) and career development. This is particularly true in any industry where it takes a team deliver a product or service.
Freelancing is a tremendous learning experience. I freelanced throughout most of college and was able to put into practice what I was learning on campus and in the classroom every day. After college, I did a stint at small software firm and then a start-up. With leads from my previous freelance work, I started out solo again after the start-up was acquired. For nearly the next two years, I worked for myself, doing hourly work and managing a few small fixed-bid projects with some other freelancers that brought in a nice profit. Making the equivalent of someone with a ‘salaried’ job in my industry with 10 years more experience, I was fortunate with the opportunities given to me.
I was billable 60% of my time. I had a 30 hour work-week. I technically had more capacity, but I took Gerald Weinberg‘s advice to do client work for three days a work-week and use the other two days for learning and getting more business. It was a great lifestyle.
I had also matured through personal experience and with the encouragement of others to realize that my calling was to build software. I love building software. Freelancing has many connotations and meanings, but it is not a vocation. It is not a calling. (Neither is “working 9-5”.) The real reason I left freelancing was the answer to this question: how do I build better software?
I realized it takes a team to build good software. I saw my limits. So, I decided to join a team (turned out to be a great team). Measuring my decision financially, I took a drastic cut compared to my freelance income (but I’m still thriving). However, there is no doubt that what I’ve gained in experience, knowledge, and opportunities for investment and growth in my craft and professional community have been incomparable to anything I could have achieved on my own.
I’ve left out many “why’s” and “how’s” of freelancing or what it’s been like since I’ve joined Pariveda Solutions or why I chose consulting – and Pariveda – in particular. Perhaps I will post further, but feel free to reach out if you have any questions.
I discovered there were natural limits to what freelancing has to offer, along with a realization of the doldrums and danger of blind self-reliance that working on one’s own can bring. While we have the rare luxury of a profession that can give us financial and ‘lifestyle’ success on our own, pursuing excellence in our craft will ultimately raise the level of commitment and community with those that we work with and for.
Earlier this week Scott Guthrie had a another round of announcements (just two weeks since the last round) of Azure awesomeness . Highlights included:
- Web Sites now support remote debugging
- WebSocket support for Azure Web Sites
- Continuous delivery support for Git in TFS
Some takeaways for me are that Azure Web Sites are receiving the same TLC as traditional Azure Cloud Services (web and worker roles). Also, Git is becoming a first class citizen in the TFS/Microsoft world. Git provides key capabilities that allows enterprises to be more collaborative than traditional TFS version control and aligns with open source development practices that foster multiple contributors across projects.
In other Azure news, Microsoft has released the Windows Azure Scheduler. It provides the often needed capability of invoking services or messages on simple or complex recurring schedule. This eliminates the need to rely on third party services or bootstrapping a service to use a task scheduler library. Sandrino Di Mattia has an excellent overview of the service here: http://fabriccontroller.net/blog/posts/a-complete-overview-to-get-started-with-the-windows-azure-scheduler/
On November 4th, the course Principles of Reactive Programming will start on Coursera: https://www.coursera.org/course/reactive. While the course is not taught in .NET, the principles are platform agnostic but is particularly targeted at building distributed and scalable systems. You can learn more about the characteristics of these systems here: http://www.reactivemanifesto.org. One of the course instructors is Erik Meijer, a former architect at Microsoft with large responsibilities in the development of LINQ and Reactive Extensions.
Current guidance on building distributed systems on Azure focuses largely on more infrastructural concerns, such as using queues or Azure Service Bus for distributing work. (See Clemens Vasters’ video blog on Channel9 and course on Pluralsight for excellent guidance in this area). This will be changing as frameworks and tools emerge that embrace the distributed nature of computing, much in the same way frameworks like Entity Framework provides a programmatic model for the database, or Web API gives a model for HTTP.
These efforts are already well underway at Microsoft. Microsoft internally uses Reactive Extensions for message processing on Azure, as evidenced by their CloudFx framework. They are also developing actor model libraries similar to Akka and Erlang that provide a simple programming model for programming distributed systems. Code-named “Orleans”, a framework similar to Akka has been in the works by Microsoft Research as far back as 2010, and is used in production by the Halo team for building real-time gaming services. ActorFx, an Actor Framework for Windows Azure, is another effort in this area to provide a language independent model for distributed systems.
While all these frameworks are at various levels of maturity (or availability), the consensus is clear in the community for the need to develop a programmatic model for building resilient and scalable systems to take advantage of both the increasing prevalence of distributed systems in the Cloud, as well as the increasing number of cores available on today’s processors. If you are building systems that require resiliency and/or scalability in a distributed or multi-core environment, understanding the patterns and solutions available to build these systems is essential to good software engineering. Of these frameworks and libraries, Reactive Extensions is already a success story, being adopted both within Microsoft and the wider community. Recent examples include GitHub’s most recent release of their .NET client features a Reactive companion package, and Netflix bringing the same concept into the Java world with RxJava, using it heavily with their APIs.
Instead of re-inventing the wheel every time we come up against these challenges, let’s learn and work together to build and master the tools needed to address and achieve the potential of today’s distributed environment.
Update: In addition to the Coursera course on reactive programming principles, Erik Meijer is offering a live course focused solely on Reactive Extensions (Rx). Sign up at https://rx.yapsody.com.
Principles of Reactive
Programming on Coursera
GitHub: Rx.NET and RxJS and more
DNR: Reactiv Extensions
Functional Reactive Programming in the Netflix API
Learn Rx in SF with Erik Meijer himself: https://rx.yapsody.com/
Orleans Project Home
Orleans Channel9 Team Interview
Microsoft opens early adopter program for its ‘Orleans’ cloud framework
Orleans: Cloud Computing for Everyone – ACM Symposium on Cloud Computing (SOCC 2011)
Understanding and Using the CloudFx Framework
CloudFx on NuGet
ActorFx Project Home
the Cloud with Actors: Inside ActorFx
Last weekend I attended Pablo’s Fiesta, an open spaces conference in Austin, Texas. There were some great sessions and discussions from everything from working remotely for Github, contributing to open source, to using NuGet at in the enterprise.
One particularly interesting session that I attended was a review of a framework that had been on my radar: Highway.Data.
It provides a consistent, clean and testable interface for data access around Entity Framework, NHibernate, or RavenDb using
an opinionated approach to data access patterns.
Highway.Data is composed of a Repository, Unit of Work (data context), and command/query object patterns for reading and manipulating data. It nicely separates the core framework from the ORM adapters such as Highway.Data.EntityFramework.
Here is an excellent run-down of the patterns and quality attributes the framework uses to guide its development: http://hwyfwk.com/blog/2013/10/19/understanding-the-patterns/. One thing that is relatively uncommon in most data access libraries here is the concept of a Query object. Refer to the aforementioned post for more discussion on that and the benefits you get from using the pattern.
This is likely going to be my go-to for using when building out projects with Entity Framework that need a good testing story.