Here’s the basic outline of what I intend to speak on at the upcoming presentation I have for the Bellingham, Washington .NET Users Group. If you happen to be in the area you should swing by and give it a listen (or heckle, whatever you feel like doing).
On April 5th I have a talk lined up with the Bellingham .NET Users Group. So far here’s a quick one over of the talk:
What Cloud Computing REALLY is to us techies
- Geographically dispersed data centers.
- Node based – AKA grid computing configurations that are…
- Highly Virtualized – thus distributed.
- Primarily compute and storage functionality.
- Auto-scalable based on demand.
What kind of offerings exist out in the wild?
- Amazon Web Services
- Orcs Web
…many others and then the arrival in the last year”ish” of…
Developing for the cloud, what are the fundamentals in the .NET world?
Well, let’s talk about who has been doing the work so far, pushing ahead this technology.
- Linux is the OS of choice… free, *nix, most widely used on the Internet by a large margin, and extremely capable…
- Ruby on Rails
- The Heroku + EngineYard + Git + AWESOMESAUCE capabilities of pushing… LIVE to vastly scalable and distributable cloud provisions!
So where does that leave us .NETters?
AWS .NET SDK released a few years ago.
Windows Azure & SDK released about a year ago.
These two have however been lacking compared to Heroku and EngineYard for those that want something FAST,
something transformative, easy to use, without extra APIs or odd tightly coupled SDKs.
In Summary the .NET Platform has primarily:
AWS for the top IaaS and most widely available zones & capabilities at the absolutely lowest prices,
Windows Azure for the general build to PaaS Solution, and for the people lucky enough to be going the Git +
MVC + real Agile route, AppHarbor is the peeminent solution.
Windows Azure Demo
I recently did a clean install of Windows 7 64-bit. It had been a really long time since I listed the current tools, SDKs, and frameworks that I’ve been using. Thus here’s my entourage of software that I use on a regular basis that is installed on my primary development machines.
Basic Software & System OS
- Windows 7 64-bit
- Visual Studio 2010 Ultimate
- Visual Studio 2010 Plugins
- Expression Ultimate 4
- Office 2010 (Rarely, I try to stick to Google Docs, to maintain usability across devices)
Themes & Such
In addition to these packages of software another as important, if not more important to my day-to-day software development includes these software services and cloud hosting services.
SaaS, PaaS, and IaaS
Software I will be adding to the stack within the next few days, weeks, and months.
So again, the #altnetseattle Conference easily was one of the most useful events of the year for me. The amount of ideas, thoughts, and conversations that happen in just those two days often outweigh all the presentations I see at other conferences throughout the year. The reason is simple, they are directed, to the point, and done with the ideal of open spaces. This makes each session exhaustive on a particular topics. Throw together some of the smartest people in the field and you have a bang up awesome energy and conversation.
I got to talk about cloud computer, a little bit, and REST Architecture as sessions I kicked off myself. Those were a blast. I also got to meet a ton of other super talented like minded developers and engineers that are out there kicking the tires of .NET (and other languages/tech stacks like Ruby on Rails).
Overall the conference rocked and I will definitely be coming back! With that, I am headed home to Portland.
- The two main concepts of Kanban is to keep the queues minimum and to maintain visibility.
- Management/leadership needs to make sure the Kanban Queue doesn?t get starved. This is key and also very challenging, being the queue needs to be minimal but also can?t get too small during the course of work. This is to maintain maximum velocity.
- Phases of the Kanban need to be kept flowing too, bottlenecks need removed ASAP when brought up.
- Victory Wall ? I dig that idea. Somewhere to look to see the success of the team.
- The POs work in Rally or other tools for some client management, but it causes issues with the lack of “visibility” ? a key fundamental ideal & part of Kanban.
- One of the big issues is fitting things into a sprint, when Kanban is used with Scrum, but longer sprints are wasteful.
- Kanban work sizes are of a set size.
At this point I got a bit side tracked by the actual conversation and missed out on note taking. Overall, people doing Kanban and Lean Style Software Development I would say are some of the happiest coders around. The clean focus, good velocity, sizing, and other approaches that are inferred by Kanban help developers be the rock stars and succeed.
This is definitely a topic I will be commenting on a lot more in the near future.
The session convened and we began a discussion about why collaboration is so hard.
- To work together in software better us engineers have to overcome traditional software approaches (silos of work) and the human element of tending to go off in a corner to work through an issue.
- It was agreed upon that software engineers are jack asses of jack assery.
- Breaking down the stoic & silent types by presenting a continuous enthusiasm until the stoic and silent types break down and open up to the group. Knowing it is ok to ask the dumb question or work through basic things once in a while.
- Non-work interactions are pivotal to work related collaboration.
- Collaboration is mostly autonomous of process (i.e. Agile or Waterfall)
- Latency time should be minimal in the feedback loop for software development.
- Collaboration is enhanced by Agile Ideals, and things like Scrum or Lean Process.
- Agile is not a process, Lean and Scrum are process. Agile is an ideal.
- Lean, Agile, Scrum, Waterfall, Six Sigma, CMMI, oh dear. . .
Great session. Off to the next session and more brain crunching. . . weeeeeeee!
I dived into the MEF session with Glenn Block, Sourabh Mathur, Brian Henderson, and others. Glenn covered the basic architectural ideas of MEF and then dived into a few examples.
- Is a framework around decoupling components.
- Built around the idea of discoverable type systems.
- Traditional extensibility mechanisms have a host and the respective extensions, commonly linking these two aspects with a form of registration.
- MEF removes the need for the registration part of the architecture and uses a contract.
- At some point with MEF you get down to parts, which removes even the complexity of a host or extensions, but a truly evolvable architecture based on natural growth of parts.
- Also referred to as the framework that removes the “new” keyword.
- The idea is that parts pull together other parts that they need. Between each part is a contract.
- Each part has imports or exports for the parts it needs or the things it offers.
If one checks out the MEF Codeplex Site you will find a host of additional information. The framework download also has some decent examples that help one get kick started.
This is a topic I know nothing about, and thus, may be supremely disparate notes. Have fun translating. : ) . . .and coolness that the session is well past capacity.
- Separates things form the UI and everything that needs populated is done through commands. The domain and reports have separate storage.
- Events populate these stores of data, such as “sold event”.
- What it looks like, is that the domain controls the requests by event, which would be a product order or something similar.
- Event sourcing is a key element of the logic.
- DDD (Domain Driven Design) is part of the core basis for this methodology/structure.
- The architecture/methodology/structure is perfect for blade style plugin hardware as needed.
- Good blog entry DDDD: Why I love CQRS and another Command and Query Responsibility Segregation (CQRS), more, CQRS ? la Greg Young, a bit by Udi Dahan and there are more. Google, Bing, etc are there for a reason.
It appears the core underpinning architectural element of this is the break out of unique identifiable actions, or I suppose better described as events. Those events then act upon specific pipelines such as read requests, write requests, etc. I will be doing more research on this topic and will have something written up shortly. At this time it seems like nothing new, just a large architectural break out of identifiable needs of the entire enterprise system. The reporting is in one segment of the architecture, the domain is in another, hydration broken out to interfaces, and events are executed to incur events on the Reports, or what appears by the description to be events on the domain.
Anyway, more to come on this later.