posted 7/15/2015 by Arthur Correa | 0 comments
Lately everywhere I look I read about the Microservice "tax".  Meaning when you implement microservices there are new dynamics involved that your company may not be accustomed to dealing with such as Additional operations overhead - Rather than just focusing on keeping one or two farms of servers up and running to a reasonable SLA you have to instead worry about as many farms as you have microservices.   Communication between services is slower than in process communications and have a higher risk of failure. Data consistency between services I completely agree with those problems, my problem isn't with the industry recognizing that there are differences with how your Microservices impact your business.  My problem is using the term "tax" to say that.  I can't think of a single instance where a "tax" is a good thing in any way shape or form.  From the time that we first understand what a tax is, we are conditioned to think that taxes are bad and somethin
full article

posted 6/16/2015 by Arthur Correa | 0 comments
One thing I've had to do a lot over the years is deal with a Monolith .  In some cases it was not a bad experience, in others it was pretty horrific.  Often Monoliths aren't an intended outcome, but unless you take explicit actions to isolate functionality as the code grows the code base will gradually grow into a Ball of Mud.  A codebase starts off as something small and focused, but then over time, it grows organically as new user stories are added to it.     As these new user stories are added the code is extended in a tightly coupled way and the Monolith can be an advantage to an organization.  It enables any of its people with the right skill set to make changes in any areas of the system.  This gives the organization a lot of flexibility in how it staffs projects, and speed in how it can effect change on its codebase.  it lets a company focus on getting the right solutions in front of i
full article

posted 6/7/2015 by Arthur Correa | 0 comments
Recently I was discussing about whether to use JSON or XML as the data exchange format for a web service.  I was surprised to hear that in today's environment my coworker wanted to use XML instead of JSON.  As for myself I pushed for JSON for a number of reasons. Now back when I first started coding years ago XML was just gaining in popularity.   At the time flexibility provided by the data structure was something new and incredibly useful.  Couple that with its ability to have defined schemas and transformations and it was a very interesting and powerful tool to use.  The first time I implemented web services in production I used XML for the requests and responses, and it worked very well.  After that I moved on and worked some SOAP services and again the XML worked really well. Then about a decade or so ago I was introduced to the idea of using JSON instead of XML.  I admit, at first I was resistant.  Why change?  XML worked we
full article

posted 4/2/2010 by Arthur Correa | 0 comments
Scott Guthrie just posted about a few new features in C# 4.0.  Optional parameters are now part of the language.  These are something that I've missed since I made the switch to C# from C++ back in 2001 (Dont' get me wrong, it wasn't the end of the world, its easy enough to work around when you dont' have them, but its nice to have them back). He also shows an example of how you could use them with ASP.Net MVC.  All in all, like usual, he has some good info so check it out. 
full article

posted 3/30/2010 by Arthur Correa | 0 comments
Admob recently postest the latest Mobile operating share number latest numbers, and its not good for the iPhone.  The Android is rapidly catching up to the iPhone in terms of US market share, to the point where its looking like the Android will pass the iPhone in the use sometime within the next month or so. Is this really a big surprise?  I've always thought this was inevitable.  The iPhone is only on a single carrier (currently), and only has a single vendor that makes and sells the hardware for it (Apple).  Android on the other hand has multiple hardware manufacturers making phones for it (HTC, Motorola, Acer, Dell, amongst others), and is available on a number of different carriers.   Android is just setting themselves up to have a bigger market right out of the gate.  On top of that, if one phone maker screws up and makes a bad phone, no big deal, there is another phone maker making a great Andr
full article

posted 1/13/2010 by Arthur Correa | 0 comments
So back in August I mentioned that I was being slow in posting because I was making the switch to NHibernate.  Well I finished that conversion about a week after that post, so what's my excuse now? At any rate lets talk about NHibernate.  First of all.  I used it in conjunction with Castle's Active Record project.  It was a really quick and clean implementation.  I converted over from LINQ2SQL in about a weekend with the worst of the changes being some minor tweaks to my Repository classes over some LINQ object naming quirks.  The fact that I had placed a Repository layer between my Services and my data store really helped with this since I had a logical place to store all my CRUD logic that was independant of my ORM classes. From a development point of view everything worked out great, a few attributes and my data was loading and saving cleanly.  Now as I mentioned I'm using a Repository pattern in my Data Layer and you may have noti
full article

posted 10/9/2009 by Arthur Correa | 0 comments
I've noticed an interesting trend lately.  Whenever people talk about Agile development or Scrum they use the two interchangeably.  Like one always means the other, and there is no other Agile process other than Scrum worth mentioning.  Why do I think this is an interesting trend?  According to recent surveys (for example here) Scrum is the most popular Agile process in use today so why not just equate the two words?  It definitely isn't a horrible idea.  Then again is Scrum really the most popular?  I can also find evidence from just a year ago that Extreme Programming is the most popular Agile process (here), but for some reason Scrum wins out, why is this the case? Ok, we'll get to that, but first what are the other options out there?  Maybe looking at those other options will give us an idea why Scrum seems to be so widely known.  Scrum is a very good process for most software projects, but that doesn't mean its a good fit f
full article

posted 10/8/2009 by Arthur Correa | 0 comments
Ok, so you've heard about Scrum and want to know what all the fuss is about.  What does it mean to say that you are following a Scrum methodology?Well Scrum is one particular way to do Agile Development.  For example there are a set of practices that are common to Scrum projects such as.The team is self-organizing.  That is there is no project manager that plans the order of work, or give guidance on how to fulfill the iteration goals.  Instead the team has the authority an dresources to make all of these decisions on their own.A Scrum cycle, which is called a sprint, is 30 calendar days (unlike most Agile methodologies the Scrum guidelines are fairly specific on this.  This is actually a practice that a lot of Scrum teams ignore and generally end up with sprints that run anywhere from 2-4 weeks).Once all the features to implement have been selected for a sprint they don't change for that sprint.  The team focuses on getting those features working, if anything else comes along they go
full article

posted 10/7/2009 by Arthur Correa | 0 comments
From what I can tell Extreme Programming (XP) is the most misunderstood Agile methodology out there.  For example one time I was giving Extreme Programming (XP) as an example of Agile development, and one person's response was "Extreme Programming?  I don't want to talk about just how you plan to write the code, I want to talk about how you're going to run your project." *SIGH*I think its name helps to tie into this sort of thing.  Some people hear the word "programming" and just shut down because they think they're going to start hearing about something technical.At any rate, I digress.  So what is Extreme Programming (XP)?  Like all the other Agile processes it focuses on frequent releases to promote the gathering of feedback and incorporation of that feedback to create a stable product that meets the customer's needs. Like other Agile methodologies XP has a set of core principles that it focuses on for success.  The team must deliver customer satisfactionThe team must deliver custom
full article

posted 10/6/2009 by Arthur Correa | 0 comments
The Unified process is yet another method of Agile Development.  One of the key strengths of this process is that it encourages its users to tweak and change it so that it meets their needs.  Activities and artifacts in this process are considered optional and can be done or not as the team decides.  Even the order in which steps are done are up to the project team.   As a result there are a number of different variatons on this including the Agile Unified Process, the Rational Unified Process, the Enterprise Unified Process, and I could go on.  At its most simple and basic the Unified Process (UP) has a number of key practicesDevelop in short timeboxed iterations. This is a common theme in all Agile processes.  Deliver quality software in short, frequent cycles.  Gather feedback, iterate, and improve upon it.Develop the high-risk/value elements early (for example get the core architecture in place). This is something that isn't called out explicitly in other Agile processes, and I thi
full article