Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

new topic

  • Loading branch information...
commit 9782a27844cedde2f6c5ada7f740220687645a3e 1 parent f4d2140
@hectorcorrea authored
View
73 data/blog.31.html
@@ -1 +1,72 @@
-this is the content
+<p>Over the last couple of months I've been meaning to update <a href="https://github.com/hectorcorrea/simple-blog" target="_blank">my sample Express.js application</a> from Express 2.x to Express 3.x but the fact that support for layouts was removed from Express 3.x was holding me back.</p>
+
+<p>In Express 2.x the framework itself supported the concept of layouts and both template engines, Jade and EJS, worked nicely with it. In Express 3.x the functionality has been removed from the framework and now the template engines need to be updated to provide this support themselves. </p>
+
+<p>This week I found that EJS has been updated to support <a href="https://github.com/visionmedia/ejs#includes" target="_blank">includes</a> and that allowed me to emulate in Express 3.x the concept of layouts that I was getting with Express 2.x. This is probably the mother of all hacks, but it's simple and it works for my purposes so I am documenting it for others using Express 2.x and EJS that might be holding back on upgrading to Express 3.x just because of the lack of layouts in Express 3.x.</p>
+
+<h2>EJS layouts in Express 2.x</h2>
+<p>In Express 2.x my <b>layout.ejs</b> file looked something like this:</p>
+
+<pre>
+&amp;lt;!DOCTYPE html&amp;gt;
+&amp;lt;html&amp;gt;
+ &amp;lt;head&amp;gt;
+ &amp;lt;title&amp;gt;&amp;lt;%= title %&amp;gt;&amp;lt;/title&amp;gt;
+ &amp;lt;link rel='stylesheet' href='/stylesheets/style.css' /&amp;gt;
+ &amp;lt;/head&amp;gt;
+ &amp;lt;body&amp;gt;
+ &amp;lt;h1&amp;gt;Header&amp;lt;/h1&amp;gt;
+ &amp;lt;p&amp;gt;Welcome to &amp;lt;%= title %&amp;gt;&amp;lt;/p&amp;gt;
+ <b>&amp;lt;%- body %&amp;gt;</b>
+ &amp;lt;p&amp;gt;the footer&amp;lt;/p&amp;gt;
+ &amp;lt;/body&amp;gt;
+&amp;lt;/html&amp;gt;
+</pre>
+
+<p>an a simple <b>index.ejs</b> file would look like this:</p>
+
+<pre>
+ &amp;lt;p&amp;gt;the content of the page&amp;lt;p&amp;gt;
+</pre>
+
+
+<h2>EJS layouts in Express 3.x</h2>
+
+<p>To achieve a similar behavior in Express 3.x I ended up (1) splitting my layout.ejs file in two files (layoutTop.ejs and layoutBottom.ejs) and (2) updating my views to explicitly include the top and bottom layout files. The following example shows this:</p>
+
+<p>The contents of <b>layoutTop.ejs</b> looks like this</p>
+<pre>
+&amp;lt;!DOCTYPE html&amp;gt;
+&amp;lt;html&amp;gt;
+ &amp;lt;head&amp;gt;
+ &amp;lt;title&amp;gt;&amp;lt;%= title %&amp;gt;&amp;lt;/title&amp;gt;
+ &amp;lt;link rel='stylesheet' href='/stylesheets/style.css' /&amp;gt;
+ &amp;lt;/head&amp;gt;
+ &amp;lt;body&amp;gt;
+ &amp;lt;h1&amp;gt;Header&amp;lt;/h1&amp;gt;
+ &amp;lt;p&amp;gt;Welcome to &amp;lt;%= title %&amp;gt;&amp;lt;/p&amp;gt;
+</pre>
+
+<p>where as the contents of <b>layoutBottom.ejs</b> looks like this</p>
+
+<pre>
+ &amp;lt;p&amp;gt;the footer&amp;lt;/p&amp;gt;
+ &amp;lt;/body&amp;gt;
+&amp;lt;/html&amp;gt;
+</pre>
+
+<p>and finally my <b>index.ejs</b> file now looks like this</p>
+
+<pre>
+&amp;lt;% include layoutTop %&amp;gt;
+&amp;lt;p>the content of the page&amp;lt;/p&amp;gt;
+&amp;lt;% include layoutBottom %&amp;gt;
+</pre>
+
+<p>Notice how the <b>index.ejs</b> explicitly requests the two layout files which is a bit annoying since in the previous version this was implicit but I think it's a small price to pay to keep the functionality working.</p>
+
+<h2>A few final words...</h2>
+<p>Although this approach is not nearly as elegant as what Express 2.x and EJS provided, I liked it because its simple enough that allowed me to upgrade to Express 3.x without having to switch template engines, download somebody else's fork of EJS, or invest a lot of time learning how to build a template engine to support this behavior.</p>
+
+<p>I am sure a more elegant solution can be achieved by taking a closer look at both the EJS and Express 3.x source code but I will leave that for another day/blog post.</p>
+
View
41 data/blog.33.html
@@ -0,0 +1,41 @@
+<p><img alt="" hspace="10" align="left" src="http://hectorcorrea.com/images/onething.jpg" />A few years ago my friend Bill from <a target="_blank" href="http://rebarbusinessbuilders.com/Contact.aspx">Rebar Business Builders</a> recommended me the book "The <a target="_blank" href="http://www.amazon.com/One-Thing-You-Need-Know/dp/0743261658">One Thing You Need to Know</a>...About Great Managing, Great Leading, and Sustained Individual Success" by Marcus Buckingham. For a while I hesitated to buy this book, initially the title about "the one thing" kind of put me off but I ended up buying it and reading it. </p>
+
+<p>Back then I knew I had enjoyed the book but until recently I didn't realize how much I took from it.</p>
+
+<p>The first thing that the book helped me clarify was the difference between managing and leading. Not only are these two roles (and the talents needed to perform them) different but they are oposite. Marcus points that the main focus of great managers are his/her employees while the main focus of great leaders is a better future.</p>
+
+<p>Here is how Marcus puts it in regards to management [p. 83]</p>
+
+<blockquote>
+The One Thing that all great managers know about great managing is this: <strong>Discovery What Is Unique About Each Person and Capitalize on It</strong>
+</blockquote>
+
+<p>and in regard to leadership [p. 132]</p>
+
+<blockquote>
+The One Thing every great leader knows he must do is: <strong>Discover What Is Universal and Capitalize on It</strong>
+</blockquote>
+
+<p>Marcus provides several examples on how <strong>great managers</strong> "see people as an end unto themselves" and "derive satisfaction from seeing tiny increments of growth in someone else". Their focus is to serve their employees first, find what is unique about each of them, care for them, and put them in situations where their individual talents shine. Great managers will go above and beyond to "rearrange the world" to take advantage of each employee's individual strengths. This in turn tends to drive productivity in employees and teams which is why companies need great managers.</p>
+
+<p>The two most important talents that allow great managers to perform their role is the ability to coach people and perceive their individual differences.</p>
+
+<p>On the other hand leaders have a different role. <strong>Great leaders </strong>"perform [their] role well only when they find a way to make many people, regardless of each person's uniqueness, excited by and confident in [a] better future" Leaders tend to be fascinated by the future and they believe they have what it takes to take people to this better future.</p>
+
+<p>The two talents that all great leaders have are optimism and ego. Optimism because they are convinced they can overcome present challenges and that there is a better way to do something. Marcus points that the oposite of a leader is a pessimistic. Ego because they believe they have what it takes to get there. As Marcus puts it, "they are not humble in their assessment of their own abilities" -- yet, this does not mean they are brash or abrasive, as a matter of fact most of them are quite reserved. [p. 66-68]</p>
+
+<p>On the Agile Management Blog, David Anderson has an interesting post on <a target="_blank" href="http://www.agilemanagement.net/Articles/Weblog/LeadWellandProsper.html">Lead Well and Prosper</a> that echoes some of these thoughts on optimism and leadership.</p>
+
+<p>I think having a clear idea of the different roles and talents needed for managing and leading is very important in software development teams, particularly as developers start getting promoted to positions in which they are expected to lead and/or manage. Each company has a different expectation on what a senior or lead developer should do. Make sure you know what your role is, what your skills are, and how to make sure you are in a position that you enjoy, can perform, and is the best for the team.</p>
+
+<p>Some people are very good at managing but not at leading, and vice-versa. Some people are good at both, some are not good at either. This is something applies to you, your peers, the people that report to you, and also to the people that you report to.</p>
+
+<p>Marcus goes as far as to claim that leaders are born, not made [p 69] He bases this claim on the fact that optimism and ego is something that people are born with, not something that leaders learn. I am not sure I agree (or disagree) with his statement -- it's an uncomfortable thought, but I am not sure it's wrong.</p>
+
+<p>The book is very good in general and I highly recommend it to people that are getting into management or leadership positions.</p>
+
+<p> </p>
+
+<b>References</b>
+<p>Buckingham, Marcus. <em>The One Thing You Need to Know...About Great Managing, Great Leading, and Sustained Individual Success</em>. 2005. Free Press.</p>
+
View
145 data/blog.34.html
@@ -0,0 +1,145 @@
+<p>One of the nice features that Windows Communication Foundation (WCF) provides is the ability to expose a single service via multiple endpoints so that different client applications can consume the same service over different network protocols. For example the same service can be exposed via HTTP for external clients and via TCP for internal clients. </p>
+<p>In WCF an <strong>endpoint</strong> refers to the combination of the address where service is available, the binding used to communicate to it, and the contract that the service exposes, these three parameters are commonly known as the "ABC" of the endpoint.</p>
+
+<ul>
+<li>The <strong>address </strong>represents the URL where the service is to be found, for example <i>http://localhost:8000/HelloWorld/HelloWorldService</i> or <i>net.tcp://localhost:9000/HelloWorld/HelloWorldService</i></li>
+<li>The <strong>binding </strong>describes the transport protocols for the communication channel, for example HTTP vs TCP</li>
+<li>The <strong>contract </strong>represents the functionality that the service exposes and it maps to a [ServiceContract] interface in your C# code.</li>
+</ul>
+
+<p>An endpoint for a WCF Service can be configured via the app.config of the service or through code. In this post I am going to focus on how to configure a service via the app.config file to be available to multiple endpoints.</p>
+
+<h2>The Service</h2>
+
+<p>So let's assume we have a simple "Hello World" WCF service that implements IHelloWorld interface like the one shown in the following code snippet. </p>
+
+<p><pre>
+[ServiceContract(Namespace="http://hectorcorrea.com/wcf")]
+public interface IHelloWorld
+{
+ [OperationContract] string Greetings(string yourName);
+ [OperationContract] DateTime TheTimeIs();
+}
+
+public class HelloWorldService : IHelloWorld
+{
+ public string Greetings(string yourName)
+ {
+ return string.Format("Hello {0}", String.IsNullOrEmpty(yourName) ? "Guest" : yourName);
+ }
+
+ public DateTime TheTimeIs()
+ {
+ return DateTime.Now;
+ }
+}
+</pre></p>
+
+<p>To host this service you can use the following code. The first line creates a host object for the HelloWorldService and the second line opens a communication channel to receive and process requests for this service. The call to host.Open() in this example will read the settings from the app.config (more on this later) to decide what endpoints will be opened for the service. The rest of the code displays what endpoints were found in the app.config for this service and finally we use ReadLine to put the host in a wait state and let it process requests as they come.</p>
+
+<p><pre>
+ServiceHost host = new ServiceHost(typeof(TheService.HelloWorldService));
+host.Open();
+Console.WriteLine("Host has been started");
+Console.WriteLine("Endpoints");
+foreach (ServiceEndpoint endpoint in host.Description.Endpoints)
+{
+ Console.WriteLine("Address: {0}", endpoint.Address);
+ Console.WriteLine("Binding: {0}", endpoint.Binding);
+ Console.WriteLine("Contract: {0}", endpoint.Contract.ContractType);
+ Console.WriteLine();
+}
+
+Console.WriteLine("Please [ENTER] to close the service host...");
+Console.ReadLine();
+host.Close();
+</pre></p>
+
+<h2>Server Side Configuration</h2>
+
+<p>The following XML shows how the different endpoints for the <b>TheService.HelloWorldService</b> are defined in the app.config. This is the config file that lives on the <em>server side</em>. Notice the three endpoints for the contract <b>TheService.IHelloWorld</b>, these endpoints expose the service via basic HTTP binding, TCP binding, and WS binding and each of them has its own URL. </p>
+
+<p><pre>
+&amp;lt;service behaviorConfiguration="TheServiceBehavior" name="TheService.HelloWorldService"&amp;gt;
+ <b>&amp;lt;!-- endpoint 1: Basic HTTP --&amp;gt;</b>
+ &amp;lt;endpoint address="http://localhost:8000/HelloWorld/HelloWorldService"
+ binding="basicHttpBinding" name="httpEndpoint"
+ contract="TheService.IHelloWorld" /&amp;gt;
+ <b>&amp;lt;!-- endpoint 2: TCP --&amp;gt;</b>
+ &amp;lt;endpoint address="net.tcp://localhost:9000/HelloWorld/HelloWorldService"
+ binding="netTcpBinding" bindingConfiguration="" name="tcpEndpoint"
+ contract="TheService.IHelloWorld" /&amp;gt;
+ <b>&amp;lt;!-- endpoint 3: WS HTTP --&amp;gt;</b>
+ &amp;lt;endpoint address="http://localhost:8003/HelloWorld/HelloWorldService"
+ binding="wsHttpBinding" bindingConfiguration="" name="wsHttpBinding"
+ contract="TheService.IHelloWorld" /&amp;gt;
+ &amp;lt;host&amp;gt;
+ &amp;lt;timeouts openTimeout="00:30:00" /&amp;gt;
+ &amp;lt;/host&amp;gt;
+&amp;lt;/service&amp;gt;
+</pre></p>
+
+<h3>On the Client Side</h3>
+
+<p>Now that we have a WCF HelloWorld service implemented and a host running waiting for requests to be send let's turn to the client side and create a simple console application to consume it. </p>
+
+<p>The following code will connect to the HelloWorld service via a proxy class called HelloWorldClient using the endpoint named "tcpEndpoint". It then makes a couple of calls to the Greetings and TheTimeIs methods in the service and finally closes the conection. </p>
+
+<p><pre>
+HelloWorldClient service = new HelloWorldClient("tcpEndpoint");
+Console.WriteLine("Greetings: {0}", service.Greetings("Hector"));
+Console.WriteLine("The time is: {0}", service.TheTimeIs());
+service.Close();
+Console.WriteLine("Channel closed.");
+Console.WriteLine();
+</pre></p>
+
+<p>In this code the class <strong>HelloWorldClient </strong>is a proxy for the <strong>HelloWorld </strong>service that we created before. The process to generate this proxy class is beyond the scope of this post (see references at the bottom of this post for more information.) In a nutshell, this proxy is a class that implements a skinny version of the HelloWorldService that uses WCF to forward the request accross the wire to the actual server. Thanks to WCF we don't have to write any of the low level networking stuff to deal with HTTP or TCP since WCF wraps that functionality for us. </p>
+
+<p>This proxy class makes the code in the client application looks like its calling a class running on the same machine as the client. By just looking at this code, you have no idea if the call to <strong>service.Greetings</strong> is to a class running on the same machine as the client or in a different machine across the country.</p>
+
+<p>So how do we tell the client where to find the real HelloWorld service? As with the server side settings you can do it either via code or using a config file. In this post I am going to show how to do it using a config file (keep in mind that this client side config file is different config from the server side config file that we discussed before.)</p>
+
+<h3>Client Side Configuration</h3>
+
+<p>Like the server side configuration file that we reviewed before, the client side configuration also has endpoints and, as you can imagine, they are subset of the endpoints that the server exposes. <i>The client side config tells the client application where to find the service while the server side config tells the server where to listen for requests.</i> </p>
+
+<p>The following XML shows how the endpoints are defined in the client side config. In this particular example we have all three endpoints for the HelloWorldService listed for illustration purposes, but we could have as well just one. You will notice that the definition of these endpoints is similar to the ones that we used for the server config file as they also have an address, a binding, and a contract. Yet, keep in mind that this is a different config file -- this config defines client side settings.</p>
+
+<p><pre>
+&amp;lt;client&amp;gt;
+ <b>&amp;lt;!-- endpoint 1: Basic HTTP --&amp;gt;</b>
+ &amp;lt;endpoint address="http://localhost:8000/HelloWorld/HelloWorldService"
+ binding="basicHttpBinding" bindingConfiguration="httpBindingParameters"
+ contract="HelloWorldProxy.IHelloWorld" name="httpEndpoint" /&amp;gt;
+ <b>&amp;lt;!-- endpoint 2: TCP --&amp;gt;</b>
+ &amp;lt;endpoint address="net.tcp://localhost:9000/HelloWorld/HelloWorldService"
+ binding="netTcpBinding" bindingConfiguration="tcpBindingParameters"
+ contract="HelloWorldProxy.IHelloWorld" name="tcpEndpoint" /&amp;gt;
+ <b>&amp;lt;!-- endpoint 3: WS HTTP --&amp;gt;</b>
+ &amp;lt;endpoint address="http://localhost:8003/HelloWorld/HelloWorldService"
+ binding="wsHttpBinding" bindingConfiguration="wsHttpBindingParameters"
+ contract="HelloWorldProxy.IHelloWorld" name="wsHttpEndpoint" /&amp;gt;
+&amp;lt;/client&amp;gt;
+</pre></p>
+
+<p>You will notice that the name (tcpEndpoint) of the second endpoint in this XML matches with the name of the endpoint that we indicated in the line</p>
+
+<p><pre>HelloWorldClient service = new HelloWorldClient("tcpEndpoint");</pre></p>
+
+<p>When this line is executed WCF will read the values of the <b>tcpEndpoint</b> from the client config file and open a TCP communication channel at the address indicated to communicate with a service that recognizes messages for the HelloWorldService contract.</p>
+
+<p>After this the calls to service.Greetings() and service.TheTimeIs() are automatically forwarded to the real service. If our service is up and running and listening for request on the same endpoint (i.e. same address, binding, and contract) it will process the request and return the expected result.</p>
+
+<p>You could change the first line to use the HTTP endpoint by just changing the name of the endpoint</p>
+
+<p><pre>HelloWorldClient service = new HelloWorldClient("httpEndpoint"); </pre></p>
+
+
+<p>That's it, with one little change the client application will now use HTTP instead of TCP to send requests to the server but <em>the rest of the code in the client application remains unchanged</em>. As I mentioned at the beginning a typical scenario is to use TCP for internal clients and HTTP for external clients.</p>
+
+<p><b>References</b></p>
+
+<p>A great book on WCF and where I learned most the information in this blog post is <a target="_blank" href="http://www.amazon.com/Learning-WCF-Hands-Michele-Bustamante/dp/0596101627">Learning WCF</a> by Michelle Leroux Bustamante</p>
+
+<p>If you want more information on how to create the proxy class used on the client two good references are <a target="_blank" href="http://msdn.microsoft.com/en-us/library/ms733133.aspx">this MSDN link</a> and Miguel Castro's article on <a target="_blank" href="http://www.devx.com/codemag/Article/39837/0/page/1"> how to do it manually</a>.</p>
View
55 data/blog.35.html
@@ -0,0 +1,55 @@
+<p>One of the best practices when building applications that I've learned over the years is the value of always having a running version of the application available to show end-to-end progress on the system being developed. Although this is common sense it's easy to get caught on the day-to-day activities and lose track of these things.</p>
+
+<p>A typical situation in which teams seem to forget the value of always having a running version of the application is when writting a brand new application. In this scenario is common to have a bunch of components half-way written and not ready for production and most development teams tend to be OK with this. I am OK with this <em>as long as they all compile and can be run successfully to show the functionality implemented so far</em>. It does not matter the system can only perform a sub-set of features that the final system will have. It should always run so that people can experience first hand how each of the modules interact with each other.</p>
+
+<h2>Walking Skeleton</h2>
+
+<p><img alt="Walking Skeleton" align="left" src="http://hectorcorrea.com/images/skeleton.jpg"/>In trying to explain this concept to a friend of mine I found that there is even a pattern that explains this idea when it comes to building new applications. Cockburn<sup>[1]</sup> calls it a <a target="_blank" href="http://alistair.cockburn.us/index.php/Walking_skeleton">Walking Skeleton</a>:</p>
+
+<blockquote>
+"A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel."
+</blockquote>
+
+<p>As Cockburn points out a Walking Skeleton is different from a proof of concept (or spike) in the sense that the later is meant to be throw away code while the Walking Skeleton is meant to evolve over time.  </p>
+
+<p>This approach relies heavily on having a procedure in place to support the evolution of the code as the skeleton is fleshed out (pun intended.) Cockburn calls this strategy Incremental Rearchitecture.</p>
+
+<p>I recommend that teams use unit testing to make sure the code that performs some basic features today remains fully functional tomorrow as new few features are implemented and the architecture of the system updated to accommodate new features and new ideas.</p>
+
+<h2>Mona Lisa</h2>
+
+<p><img alt="Mona Lisa" align="left" src="http://hectorcorrea.com/images/monalisa.jpg"/>On his article <a target="_blank" href="http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=13178">The Neglected Practice of Iteration</a> Jeff Patton talks about the difference between iterating and incrementing (no, they are not synonyms) and touches on the idea of a Walking Skeleton from a different angle.</p>
+
+<p>Jeff uses a Mona Lisa drawing to describe the differences between an iterative and an incremental approach to software development. If we were to use a <em>pure incremental </em>approach to drawing the Mona Lisa we would start by drawing to perfection a section of this paiting (say her hands), then we'll draw completelly her arms, then her face, and so on and so forth. Using an iterative approach we would start by drawing a sketch of the Mona Lisa in pencil (that's our first iteration), then we'll do a second iteration in which we increment the detail and perhaps give some coloring to the drawing, then we'll do a third iteration and put the final touches (keep incrementing the detail) on the painting. His article has great images that show this graphically.</p>
+
+<p>The point of Jeff's article is that you need both (iterations and increments) in software development. A lot of people thing these two words are synonyms and use a pure incremental approach in which they work one a single module of the software to perfection before moving to the next module. The pure incremental approach has the disadvantage that neither the user nor the developers get to see the complete picture until the system is complete...and by then is usually too late. By using an iterative and incremental approach both the users and the developers get a rough idea of the whole system early on and how each module relates to each other.</p>
+
+<h2>Depth-First versus Breadth-First Problem Solving</h2>
+
+<p>On their book Lean Software Development the Poppendiecks<sup>[2]</sup> talk about two different ways to solve problems: Depth-First versus Breadth-First.</p>
+
+<blockquote>
+"Breadth-first problem solving might be thought of as funnel, while depth-first problem solving is more like a tunel. Breadth-first involves delaying commitments, while depth-first invokes making early commitments."
+</blockquote>
+
+<p>The breadth-first approach is similar to the Walking Skeleton in the sense that aim first to get an application running end-to-end and then incrementally update its architecture as more is known about the problem domain.</p>
+
+<p>I think both approaches are complimentary, just like incremental and iterative are. There are times where breadth-first is preferred over depth-first and vice-versa. The Poppendiecks put it in these words:</p>
+
+<blockquote>
+"Notice that both breadth-first and depth-first approaches require expertise in the domain. A depth-first approach will work only if there was a correct selection of the area to zero in on. Getting this selection right requires two things: someone with the expertise to make the early decisions correctly and assurance that there will not be any changes that render these decisions obsolete. Lacking these two conditions, a breadth-first approach will lead to better results."
+</blockquote>
+
+<p>One of the observations that the Poppendiecks made on their book is that "most novice designers are biased toward the depth-first approach." The irony on this is that depth-first requires people to get the decision right early on, something that a novice designer (by definition) probably won't do. Further more, I believe this bias on novice designers is the reason they tend to apply a pure incremental approach instead of an iterative and incremental approach.</p>
+
+<p>Breadth-first work better than depth-first when the knowledge of the business domain is expected to evolve (as it typically does in software development) and it is also very effective when the domain is stable (e.g. you have strong knowledge about the problem domain.) Again, in the words of the Poppendiecks:</p>
+
+<blockquote>
+"A breadth-first approach requires someone with expertise to understand how the details will most likely emerge and the savvy to know when the time to make commitments has arrived. However, the breadth-first approach does not need a stable domain; it is the approach of choice when the business domain is expected to evolve. It is also an effective approach when the domain is stable."</blockquote>
+
+<p>Personality types play a big factor in the way people use breadth-first or depth-first approach. This is an important consideration since there are probably people in your team that would favor one approach over the other. This is OK. Remember that these approaches are complimentary. When you are not sure about the domain use a breadth-first approach, once you know enough and are ready to make a commitment go deep.</p>
+
+<p><b>References</b></p>
+<p>[1] Cockburn, Alistar. <em>Crystal Clear A Human-Powered Methodology for Small Teams</em>. 2005. Addison Wesley. Pages 49-53.</p>
+<p>[2] Poppendieck, Mary et al. <em>Lean Software Development An Agile Toolkit</em>. 2003. Addison Wesley. Pages 60-62.</p>
+
View
5 data/blog.36.html
@@ -0,0 +1,5 @@
+<p><img width="120" height="62" hspace="5" align="left" alt="" src="http://hectorcorrea.com/images/pivottable.jpg" />A few years ago I wrote an article for the <a target="_blank" href="http://utmag.com">Universal Thread Magazine</a> on how to create reports using Excel's Pivot Tables. The article was titled <strong>Programming Rubber Band Reports with Pivot Tables</strong> and showed how to create Excel Pivot Tables from a Visual FoxPro (VFP) application. </p>
+
+<p>Although the article is more than 6 years old I still get questions every now and then about the code samples that I mentioned in the article. The code samples mentioned in the article can be found at <a href="http://hectorcorrea.com/downloads/correa_pivottablesvfp.zip">http://hectorcorrea.com/downloads/correa_pivottablesvfp.zip</a> A VB.NET version of the code can be found at <a href="http://hectorcorrea.com/downloads/pivottable.zip">http://hectorcorrea.com/downloads/pivottable.zip</a></p>
+
+<p>A PDF version of the article can also be found <a target="_blank" href="http://hectorcorrea.com/downloads/correapivottableswhitepaper.pdf">here</a>.</p>
View
23 data/blog.37.html
@@ -0,0 +1,23 @@
+<p>One of the topics that I've been noticing for a while is how we (as developers) tend to worry about our software development process and try to educate ourselves on the topic while other project stakeholders don't seem to show as much interest on it.</p>
+
+<p>For example, I often talk to other developers who are trying to implement Scrum, RUP, or other software development process at their companies and they fell that other project stakeholders (executives, business owners, analysts) are not as interested in the process as they should. It seems that it's always developers trying to drive these initiatives.</p>
+
+<p>The most interesting part, however, is that process improvement is not an activity that should be left alone to developers, not even when is about software development process. If the software has an impact on the bottom line of the company (and it usually does) it should be an activity that is done in collaboration with executives, business owners, QA, and developers. Developers, as well intended as we might be, don't always see the whole picture and we are bound to make one-sided conclusions. Or as <a href="http://blog.businessofsoftware.org/2007/10/an-angry-mans-s.html">Buxton</a> says</p>
+
+<blockquote>"the typical approach of software engineers having sole responsibility for new product development [is like] an ice hockey team with all goalies. No matter how good your goalies are, they aren’t going to beat even a bad team with the proper mix of players."</blockquote>
+
+<p>One of my co-coworkers had the great idea of taking a couple of business owners to our local Agile user group and they both seemed to have enjoyed it and learned a few things. Yet, that was the only time they attended one of these meetings.</p>
+
+<p>I've given books on Scrum and Lean Software Development to some of our product owners with moderate success. Although they read it, it usually fails to spark ideas on what else we should be doing.</p>
+
+<p>From what I've seen there are several reasons why most non-software developers don't pay as much attention to software development process improvement as they should:</p>
+
+<p><ul>
+ <li>Software is just a small part of their job. They deal with it because they have to (e.g. the business needs a new software to help in the creation of X, but X is the real goal and software is just a necessary evil.) Although I've seen people not care too much about software development process even on software development companies where X is a piece of software!</li>
+ <li>Everytime there is a conversation about process improvement it inevitably turns into a discussion about software tools and other geeky issues where they feel lost.</li>
+ <li>They don't think there is anything wrong with the existing process.</li>
+ <li>Althought they see problems with the existing process but they thing that's the way it is.</li>
+ <li>They just haven't realized they could participate on it and that is on their best interest doing so.</li>
+</ul></p>
+
+<p>This is an open invitation to all project stakeholders (executives, business owners, QA, developers, users) to jump into the software development process improvement in your company. Talk to your team members and see what you and others can do to develop better software and get it to your users more often.</p>
Please sign in to comment.
Something went wrong with that request. Please try again.