Web Content Life Cycle

 Joe teaches us what he has learnt about Web Content Life Cycles...

After spending some time looking over different people’s views on web content life cycles I have decided to put my own opinion out there. 

There have been vast changes in what is thought to be involved in the life cycle of web content. The way that I understand “Web Content Life Cycle” is the different phases that your content goes through from start to finish including the idea of it through to it being replaced. 

It all started with the idea of contents life consisting of two phases which were collecting and delivery. This would be writing the content and publishing it, nothing more that. There have been various other suggestions including the humorous suggestion of there being 15 stages to the web content life cycle. 

My opinion is very similar to that of CM Pros which is that there should be 6 main stages but each stage is broken down into a few different parts. These stages are:

Plan, Develop, Manage, Deploy, Preserve and Evaluate. 

Each stage is then broken down for example Develop, consists of Create, Capture, Collect, Categorize and Edit. By breaking down each stage means that each corner of the process is covered and the best content is delivered. 

I believe that not all content needs to be replaced regularly and that if content is good and strong with a few tweaks and updates it can stay good informative and strong. This goes with the stage preserve, updating and adding to existing content is a good way to keep it alive and not having to come up with new content to replace it. 

By using this method of updating and evaluating your content you can keep it as up to date, valid and relevant as possible. Having up to date relative content is extremely important as the more relevant your content the better for SEO purposes. Content will become outdated at some point and will need to be replaced to stop it becoming legacy content and it being useless. This is when the evaluation will tell us that it is time to replace the content with new fresh ideas and information.

Christmas List for Geeks and Engineers

Today is Black Friday in the US. It's the day after Thanksgiving Day and traditionally the start of the Christmas shopping rush. It's the busiest shopping day in the US every year. If you're like me, that will fill you with paralysing fear. The queues, the commotion, the clothes falling off the hangers. It's terrifying out there. But hurrah, technology has saved us once again! Jump online and have it delivered to you whilst you get on with your life. 

So, whether it's for a friend, colleague or loved one, here's our list of Christmas present ideas for those software nuts and computer geeks. Don't worry, we're not turning into a shopping channel or GQ magazine showcasing the "hottest and slickest" gadgets no-one can really afford, this is a fun Friday lunchtime post to embrace our inner nerd.

 

1.  CPG6 GRID-IT TM Organizer $9.99

Keep cables, wires and gadgets tidy with this nifty organiser.

   2. Wipe T Shirt $89.00

This smart T shirt  has a convenient, built-in microfiber cloth to wipe your glasses or mobile phone. 

3. Personalised QR Code Christmas Card on Etsy Approx £2.49

Embrace Christmas 2.0 and send a personalised message on a QRistmas card. 

 

 4. Binary Code Heart with I Love You Print on Etsy Approx £9.97

Say I love you to your partner in a way that they understand. 

5. "Backspace" T-shirt from Threadless  $10.00 (Mens and Womens sizes available)

Everytime you hit the backspace key, imagine that the cursor doing the moonwalk. How can you not be smiling?

Now, remember your Paypal password and get clicking. This activity contains no queues, no unhelpful sales assisstants and no need to fight for survival. Enjoy.

Don't Try to Run Before You Can Walk - Understanding Existing Code

This week, Joe puts on his programming hat and straps his matching trainers but soon learns that it's hard to run before you can walk...

The most important lesson that I have learnt in recent weeks is that before I am going to change something I need to understand what it did before. It all makes sense now, how can you change something and make it better if you don’t understand what and how it did whatever it’s doing before? By not understanding what something does but trying to change it to make it better is the same concept as trying to run before you can walk. 

Spending hours reading over the same lines of code trying to put pieces together and understand what it is the code is doing and why has been one of the things I have struggled with most in my journey so far.

I have now realised that I don’t need to spend hours reading over the same lines but I can run through a section of code line by line and just comment in what each bit is doing. Derek and I spent a short amount of time looking at a few lines of code that I had been studying for at least 3 hours. I hadn’t quite grasped what was happening or why. Within minutes Derek had told me just to comment each line of code as we go through saying in English what that line is doing. By doing this I had started looking at a line individually rather than everything together which meant that I could now break the code down and understand it. 

I’ve started to deal with SQL queries with some of the different alterations I have been making over the last week. I came across one of our queries in the database which had a huge number of different sections and tables added and linked to it. Looking at a query of this size scared me at first as I had no idea where to start when trying to use it to gain the right information out of it. After actually reading through it, it became quite clear that all I needed to do was to select in the code the correct field of information that I wanted to know from the results of the query. 

By taking over a project that someone else has been managing for quite a long time puts me in the position of having to read, understand, edit and add to someone else’s code. From being able to do this successfully means that my knowledge of VB is increasing vastly. I am able to break down different sections of code that once upon a time I would have just shook my head at and walked away to now being in the position to have a quick look at it in a logical way and work out what is going on. 

My journey is always changing and always going in the right direction, UP! I am constantly learning and progressing in what has been a short amount of time but large amounts have been achieved. I have gone from an absolute novice to being able to work my way around VB with a little bit of class and make some quite simple but very beneficial programs and functions. I can’t wait to be telling you all in my next chapter in my Programming Journey.

Can you remember your first experiences of programming? Do you have any advice to give to those who are just starting out? Tell us here and let others know and pass on your wisdom to the next generation of enthusiastic software engineers. 

 

Steve Jobs and Dennis Ritchie's Guide to Success

Within four days the world lost two of the greatest technology pioneers. Apple’s CEO and founder, Steve  Jobs and Dennis Ritchie, an American computer scientist  and co-creator of the programming language C and operating systems such as Multics and Unix. Jobs’ and Ritchie’s characters couldn’t be more different. Jobs was known to be fiery and ruthless whereas Ritchie was humble and gentle. Catherine finds that despite being like chalk and cheese, they were both innovators who found a code to success...

Steve Jobs and Dennis Ritchie’s Code to Success 

1.   Reverse a trend. Ritchie and Jobs went against the grain and created something unexpected and new. They say that Jobs knew what customers wanted before they wanted it. Ritchie and his partner Kenneth Thompson felt that operating systems were too complex and they “attempted to reverse the trend” with the UNIX operating system.

2.   Make technology simple. The UNIX operating system was created to make computing as simple as possible and the vision for C was to create a programming language at a higher level of abstraction that people would understand and use. In the same breath, Apple’s intuitive, fuss-free iPods are cited as being one of the greatest gadgets of all time.

3.  Create a community. Ritchie explains that UNIX was created not just to be a good programming environment in which to do programming but a system around which a community or a fellowship could form. He said “close communication” was of key importance. Apple on the other hand created devices and a brand so iconic that they created a cult following so loyal they would rather go without than not have the little munched apple stamp on their phone or computer. The world boils down to a defined matrix of two hemispheres, two genders, and whether you’re a part of the Apple movement or not.

4.    Make it easy on the eye. UNIX was created to have “graceful facilities for decomposing complex computer tasks into simple subtasks”. Now, who’s to argue that Apple’s operating system isn’t graceful and their apps decompose life’s complex tasks into a small series of manageable subtasks.  

5.    Let the technology take centre stage. Their success wasn’t about them; it was about what they created. Jobs and Ritchie were both private men. One of Ritchie’s colleagues says of him, "I worked across the hall from him for more than 20 years, and yet I feel like don’t knew him all that well.” Steve Jobs on the other hand was the same but his insistence on leading a private life only fuelled the cult of personality that surrounded him.

Steve Jobs' Golden Apple

The golden apple is featured in legends and fairy tales as divine food or a source of immortality. Steve Jobs retrieved the golden Apple in this story but it is his legacy which is immortal and lives on. Joe tries to uncover how Jobs shaped Apple...  

He's the man that people have been calling a genius in business and an inspiration. Steve Jobs was the co-founder of Apple and ran a very tight organization with high levels of secrecy, going to extreme lengths to live up to his perfectionist way of doing business and being involved with everything to do with Apple. 

Jobs was a workaholic who remained CEO of Apple up until 6 weeks before his death. Taking so much pride in his creations and working life meant that he inspired people he worked with. He had very controversial leadership style which made Apple what it is today. Being a perfectionist meant that it was up to Jobs' employees to live and work to those standards. He was all about user experience being the true top priority. This meant that any small visual flaws in design overlooked everything else and would be classed as failure. Employees said “By being both unreasonable and right, he taught us to create products to delight people, not just satisfy them.” Steve Jobs promoted his perfectionist attitude around Apple and forced it into work that was done for him and made people realise that the reputation of Apple was at stake with any work that was being done. 

“Loose lips might sink ships,” These are the words that were on the poster in Job’s office. The high level of secrecy within Apple was down to Job’s. He would insist on random phone and computer checks to make sure nothing was being leaked to the press about upcoming products which has meant that when a new product is coming out from Apple it is actually new not something that is awaited by the public. 

Steve Jobs is the man that has left an imprint on just about all of our lives in one way or another. He transformed so many different markets such as music and phones forever. Steve Jobs will always be looked at as an inspiration to countless amounts of people for a countless amount of things he brought to the world.

When the Bough Breaks – Alternate Scenarios

Alex returns with his blog post series on understanding use cases... 

Wow, it’s been four months since I wrote my piece on primary scenarios so this is severely overdue. I choose to blame this on the fact that one of our account managers, Ajay, appears to be offended by the idea that my calendar can have days in it that have no entries at all and does everything in his power, successfully I might add, to account for every minute of every day of my life. This has actually become something of a joke with many of our customers who, when asking me if I’m available to do something, “understand” that I must first get permission for Ajay before replying. Enough about my scheduling situation, were here to talk use cases. 

 Our previously defined primary scenario details the required behaviour of the system under “ideal” conditions and is useful in the understanding of customer requirements. The thing about customer requirements is that, even the most thoroughly defined, requirements are likely to only specify the nominal behavioural flow. Most of the customer requirements that I have read are significantly lacking in detail when things don’t go according to plan.

The use case primary scenario provides us with a clearer understanding of what it is that our customer requires but what about the things that they didn’t take into account? It is here that the alternate scenario provides answers or, in the case of most requirements, questions that need answering.

The identification of alternate scenarios is a three step process:

• Run through each step in the primary scenario and ask yourself; “what could happen differently?” to produce a list of potential alternate conditions
• Rationalise the list by removing those that the system cannot or does not need to handle and merging the ones that will be handled in the same way
• Write the scenario for each condition in the rationalised list.

During the identification of alternate conditions you should be looking for things such as:

• Incorrect behaviour on the part of either the primary or supporting actors
• Timeouts; one of the actors failing to provide a required interaction

When writing an alternate scenario the alternate condition becomes the trigger and then all we have to do is write what happens next until one of two things happen; either the primary scenario is re-joined or the use case ends because the goal cannot be achieved.

Typically the documenting of alternate scenarios is where use cases provide the most benefit in highlighting the inconsistency and incompleteness of the customer requirement.

Finally one should repeat the process on each of the alternate scenarios to identify possible alternates upon the alternates. Obviously this could be applied recursively through many levels however I tend to find that if you need more than two layers of alternates you should reconsider the scope of the use case as it is highly likely that you have attempted to include multiple capabilities that should each have their own use case.

Even with only two layers of alternates it is possible to develop far more scenarios than are actually needed, so, be sure to always question if what you are writing is adding to the required understanding of the system under development.

Next time I’ll look at how we model common and specialised behaviour in our use cases.

Model Driven Development: Past and Future

In the first in a series of interviews about UML and Model Driven software, Todd speaks with expert Rafael Chaves of Abstratt Technologies to find out his opinion on model driven development...

Todd Humphries: Did you have a 'Eureka!' moment when modelling made sense for the first time and just became obvious or was there one particular time you can think of where your opinion changed?

Rafael Chaves: When I was first exposed to UML back in school it did feel cool to be able to think about systems at a higher level of abstraction, and be able to communicate your ideas before getting down to the code (we often would just model systems but never actually build them). The value of UML modeling for the purpose of communication was evident, but that was about it. I remember feeling a bit like I was cheating, as drawing diagrams gave me no confidence the plans I was making actually made a lot of sense.

After that, still early in my career, I had the opportunity of working in a team where we were using an in-house code generation tool (first, as many have done, using XML and XSLT, and later, using UML XMI and Velocity templates, also common choices). We would get reams of Java code, EJB configuration files and SQL DDL generated from the designer models, and it did feel a very productive strategy for writing all that code. But the interesting bits (business logic) were still left to be written in Java (using the generation gap pattern). It was much better than writing all that EJB boilerplate code by hand, but it was still cumbersome and there was no true gain in the level of abstraction, as we would model thinking of the code that would be generated - no surprise, as there was no escaping the facts that we would rely on the Java compiler and JUnit tests to figure out whether the model had problems, and in order to write the actual business logic in Java, we had to be very familiar with the code that was generated. So even though I could see the practical utility of modeling by witnessing the productivity gains we obtained, there was a hackish undertone to it, and while it worked, it didn't feel like solid engineering.

It was only later, when I was doing research for my Masters, and I was finally exposed to the approach of executable modeling and MDA, that I finally understood there was authentic value to modeling. Real gains in level of abstraction. Validation and execution of models long before a target platform was even chosen. Full code generation, including business logic. Ultimate platform independence. It finally made all the sense in the world. It made so much sense to me that I could not believe that was not how everybody was writing software. Since then, I have been obsessed with building tools to help bring the approach to the mainstream.

TH: What would you like to see in future versions of the UML standard? What do you think UML is lacking that would help MDD progress?

RC: I actually wrote a post about this a while ago which I think addresses that exact question:

http://abstratt.com/blog/2010/02/08/uml-may-suck-but-is-there-anything-better/

TH: You've written in the past about misconceptions and myths you've come across trying to promote MDD, in your experience is it usually experienced software engineers or new graduates who are the most accepting of  modelling principles and why do you think that might be?

RC: Talking specifically about MDD (and not modeling in general): I think in general less experienced developers will buy into MDD more easily than more experienced developers. More senior folk will tend to resist more to the idea that the much of what they do (and are very proud of) could be done automatically.

Re: modeling in general - I, for one, will resist to the idea of modeling as something inherently beneficial - unless your models are actually what drive the software development (they are the primary artifacts), I see modeling as superfluous and wasteful.

TH: Do you think MDD is easier to pick up for someone who has little to no 'real-world'/practical experience of software development or for those with many years traditional development experience?

RC: Hard to say - I do think experience is usually beneficial, and a more experienced modeler will in general produce better results than a novice modeler. OTOH, I think it is much easier for a novice developer to build high quality applications using the MDD approach than manually crafting the application (because MDD allows you to encapsulate and reuse skills/expertise).

TH: Are there any books, blogs or other sources that you would recommend for someone new to or inexperienced with MDD?  Any tips of your own or those that helped you that you'd care to share?

RC:

Read the MDA Guide 1.0  

Join the ModelDrivenSoftwareNetwork
Read about Executable UML
Follow @seidewitz on Twitter
H. S. Lahman recent book (Model Based Development)
Markus Volter book on MDSD is a good introduction as well.

Study the codebase of enterprise applications in Java or C# (or even RoR) and look for the implementation patterns 

Look at an application and learn to consciously separate problem domain concerns (which are implementation independent) and solution domain concerns (which are implementation specific)

TH: Back in November last year you said "I think we still live in the dark ages of software development And, what is your vision or dream of how software development might look in ten years? Twenty?

RC: We would use a language that is at higher level of abstraction than 3GLs which would allow us to naturally express technology independent solutions, and then target different platforms with ease. The target platform won't put constraints on how we reason about solutions, and the development tool we use won't put constraints on what platform we target.

There will be a market for reusable business applications (which can target multiple platforms), and a market of target platform-specific code generators (which can accept applications from different domains).

 

This is a great introduction to UML for beginners as well as being interesting to those who are working with executable modeling and been through it all... 

Thank you Rafael for such considered answers and creating a great read!  

Joe's Database Delight

Joe becomes more of a computer nerd with each passing day.

 Trainee software engineer, Joe learns about databases and continues on his journey into becoming a real software wizkid...

The last couple of weeks have been a very steep learning curve in my programming process. I have had some intense lessons in things such as databases and VB6. I started to get a little more confident in my programming abilities, being able to make small functional programs that did simple task. 

I got to this stage and thought I was clean sailing from there and thought it would just be more of the same stuff for a while. Wow, was I wrong! I was given the on-going task of taking over and maintaining our in-house administration tool. This tool was made in VB6 some years ago and we saw it as the perfect project for me to expand my existing knowledge and give me the chance to work on a project that would actually be very beneficial to the company. The first thing that I did was spend a day just trying to get my head around the tool. It was totally new to me and the project just seemed huge. Once I had spent a day or two studying the code and which paths different functions were taking I started to understand how things were working a bit. 

The next step was to actually try and make some changes to it. The first couple of changes I made were very simple but all the same I thought I was doing amazing actually being able to change something for the better in a project of this size! All I was doing was changing the maximum amount of characters that could be entered into a text box. After I had made these changes I was given the task of automatically generating an email and populating it with a subject, a set of email addresses and with a body of text. 

My first lesson was a quick but informative lesson on databases. Derek and Todd ran me through how a database works, how they are linked together and how to call information from the database using queries. Once I had learnt that it was then time to try and pull everything I had learnt together and with a bit of help from Derek I managed to make the function that did exactly the right job that we wanted to achieve. I was so happy with the progress that we had made and that I had made a working function that would be largely beneficial to the company. 

This was not the end though. Although I had thought it was ready to be published and become part of the company’s in-house tool, I was wrong. We discussed making it into a HTML email. It was like being put back to square one again as I knew absolutely nothing about html emails. After doing some research and spending some time with Fiona we came up with the html email that we wanted to be in the body of the email. We then worked out that if we wanted to change the body of the email we didn’t want it to be hard coded into the function. We decided to make the function take the contents of a document which contained the body of the email so if we ever want to change the email we just had to replace what was in the document. 

So, there it was, my first big change to the company’s most important in-house administration tool. Needless to say I am very happy with what I have achieved over a short period of time and I can’t wait for what is next.

Needless to say, we're impressed with how much Joe has learnt since being with Objektum Solutions and proud to have him on the team!