Hello again from Cyberspace! Time for a two-part post!
These posts are dedicated to Japan's favorite car company, Toyota. But we aren't here to talk cars - instead we are going to examine the method of doing business developed by Toyota, lovingly referred to as "Lean". For the first entry, I will be summarizing an article called Lean Primer written by Craig Larman and Bas Vodde, which can be downloaded from the Lean Primer website.
The term "Lean Production" was coined by MIT researchers, and the intention is to contrast the idea of "Mass Production". Often confused for reduction of waste, the true focus of Lean is to "watch the baton, not the runner". In other words, companies should be concerned about product quality, not the actions of the employees. Often in the west, we are more concerned with employee activity, and I'm sure you've had a manager that hated the idea of you not having anything to do.
There's more to it than baton-watching, though. Really, Lean is a way of thinking, with an emphasis on respect for the customer. The customer could be the person purchasing your product, but it can also be a supplier or the next person on the assembly line. When you respect the customer and do your best to make their experience as simple and hassle-free as possible, you will find problems and endeavor to fix them. That leads to continuous improvement, and all the other processes associated with Lean. The goal is that, when you respect your customer, all of the 'reduction in waste' and 'challenge everything' comes from a desire to make life excellent for your customer.
Unfortunately, there are some misconceptions about what Lean is. Some have tried to take pieces of Lean and implement them without the overall culture shift that is at the heart of Lean. For example, the Management Tools associated with Lean, or overall waste reduction. While these are a part of lean, they do not encompass all of Lean. Without changing the mindset to respect others and empowering your employees to improve the processes all around them, you are not truly using a Lean methodology. Lean is really a a mental shift, both in how to treat your customers and employees, and any improvements or processes are born from this shift, rather than for the sake of a better process.
The respect for people is shown in the continuous learning of it's employees. Each employee is trained in the Lean way of thinking and how to spot waste and issues to report them, and all of this is taught by the managers. Rather than sitting behind a desk and passing down verdicts, managers are expected to go see the issues for themselves. The saying that particularly struck me was "My manager can do my job better than me". I wonder how many American employees can say that about their current managers?
Another major term associated with Lean is Kaizen (改善), the relentless focus on continuous improvement. The improvement is for the customer, but goes beyond that - it is improvement just for the sake of improvement. Stated another way: the relentless pursuit of perfection.
Of course, there's much more to Lean than what can be outlined here. Hopefully, this overview gave you a good idea of what Lean is all about. In the next post, I will give you my thoughts on the article. Stay tuned!
Saturday, March 17, 2012
Monday, February 27, 2012
Pegasystems BPM
Hello again from Cyberspace!
This post is dedicated to the Business Process Management (BPM) company Pegasystems. Pegasystems, or Pega according to their website, is one of the world leaders in using BPM to help companies streamline existing processes and create new systems. Not only do they offer BPM consulting, but they also work with Customer Relationship Management (CRM).
Started in 1983 by Alan Trefler, Pega works with its own version of BPM modelling to improve business procedures. Their motto, Build for Change, is demonstrated through their consulting services. They focus on training employees quickly to enable change to continue throughout the organization, according to their website.
Pega offers several services, including Consulting, University of Pega, and Pega Product Support. Consulting, as already mentioned, offers in-depth consulting support for updating a company's existing processes or creating new ones. The consultants help with Design Review, Application Readiness, Performance Health Checks, Implementation, Usability, and more.
The University of Pega is an educational environment focused on teaching the Pega method of BPM. The offerings come in the form of eLearning, Certification Programs, and Instructor-led programs, both online and in-person. These offerings can be done on-site as well as individually at one of their training centers. If you're in the States like me, grab that frequent flyer card since most of them are offered in England. If that doesn't work, you can always hop a jet to Tokyo to find more classes.
The final offering is Pega Product Support. If you are like me, the title may be a little misleading. I assumed it was some sort of call center, but it appears to be a collection of FAQ's, a knowledge base, Product Update listings, and discussion forums. All this good stuff requires a username and password, so I wasn't able to peruse the offerings. According to Pega's Product Support page, the support site is also monitored by Pega experts ready to answer your questions.
Given their location in the Gartner Magic Quadrant and the Pegasystems website, it seems like Pega is good at what it does. Before researching the company, I must admit I had not heard of them. Now that I have looked into them, I must say they appear to know what they are doing. I was especially impressed that a British company had so many American success stories posted on their website. If you need some processes mapped, you would do well to give Pega consideration.
This post is dedicated to the Business Process Management (BPM) company Pegasystems. Pegasystems, or Pega according to their website, is one of the world leaders in using BPM to help companies streamline existing processes and create new systems. Not only do they offer BPM consulting, but they also work with Customer Relationship Management (CRM).
Started in 1983 by Alan Trefler, Pega works with its own version of BPM modelling to improve business procedures. Their motto, Build for Change, is demonstrated through their consulting services. They focus on training employees quickly to enable change to continue throughout the organization, according to their website.
Pega offers several services, including Consulting, University of Pega, and Pega Product Support. Consulting, as already mentioned, offers in-depth consulting support for updating a company's existing processes or creating new ones. The consultants help with Design Review, Application Readiness, Performance Health Checks, Implementation, Usability, and more.
The University of Pega is an educational environment focused on teaching the Pega method of BPM. The offerings come in the form of eLearning, Certification Programs, and Instructor-led programs, both online and in-person. These offerings can be done on-site as well as individually at one of their training centers. If you're in the States like me, grab that frequent flyer card since most of them are offered in England. If that doesn't work, you can always hop a jet to Tokyo to find more classes.
The final offering is Pega Product Support. If you are like me, the title may be a little misleading. I assumed it was some sort of call center, but it appears to be a collection of FAQ's, a knowledge base, Product Update listings, and discussion forums. All this good stuff requires a username and password, so I wasn't able to peruse the offerings. According to Pega's Product Support page, the support site is also monitored by Pega experts ready to answer your questions.
Given their location in the Gartner Magic Quadrant and the Pegasystems website, it seems like Pega is good at what it does. Before researching the company, I must admit I had not heard of them. Now that I have looked into them, I must say they appear to know what they are doing. I was especially impressed that a British company had so many American success stories posted on their website. If you need some processes mapped, you would do well to give Pega consideration.
Sunday, January 15, 2012
SAD SWEBOK
Hello again from CyberSpace!
No, that isn't a picture of a sad swebok we will be discussing. This post is dedicated to Software Analysis & Design (SA & D), as outlined in our course textbook and Software Engineering Body of Knowledge (SWEBOK) methods of process design. I'll review the two methods, highlighting the differences between the two.
To start, we'll outline the different approaches. The textbook version has 6 steps:
SWEBOK is a ten step process, and focuses more heavily on the software aspect of design:
At the outset, we can expect that several of these to be different just based on numbering. In fact, half of the lists are the same: Identify and understand requirements, design the software, build the software, then test and launch the software. #2 in SA & D can arguably be added into #1 in SWEBOK given the breadth and depth of requirements setup in SWEBOK. And while Understanding the Issue isn't expressly listed in SWEBOK, the depth of planning and designing in SWEBOK cannot be achieved without a thorough understanding of the issue, even that isn't expressly listed as a step.
That brings us to the items in SWEBOK that are not present in SA & D, specifically items #5 - #10. A major difference in the methodologies is the scope; SA & D is broad enough that it could apply to many process designs, not just software, where SWEBOK is much more focused on developing software. Since these are not covered in SA & D, let's briefly cover them:
There you have it - two different ways to design a software system. They are very similar in topics, and really only differ in the order of planning. SA & D is more focused on planning and control before design, where SWEBOK manages this aspect of design later in process.
No, that isn't a picture of a sad swebok we will be discussing. This post is dedicated to Software Analysis & Design (SA & D), as outlined in our course textbook and Software Engineering Body of Knowledge (SWEBOK) methods of process design. I'll review the two methods, highlighting the differences between the two.
To start, we'll outline the different approaches. The textbook version has 6 steps:
- Identify the problem and obtain approval to proceed
- Plan and monitor the project
- Discover and understand the details of the problem
- Design the system
- Build and test the system components
- Complete the test and deploy the solution
SWEBOK is a ten step process, and focuses more heavily on the software aspect of design:
- Software requirements
- Software design
- Software construction
- Software testing
- Software maintenance
- Software configuration management
- Software engineering management
- Software engineering process
- Software engineering tools and methods
- Software quality
At the outset, we can expect that several of these to be different just based on numbering. In fact, half of the lists are the same: Identify and understand requirements, design the software, build the software, then test and launch the software. #2 in SA & D can arguably be added into #1 in SWEBOK given the breadth and depth of requirements setup in SWEBOK. And while Understanding the Issue isn't expressly listed in SWEBOK, the depth of planning and designing in SWEBOK cannot be achieved without a thorough understanding of the issue, even that isn't expressly listed as a step.
That brings us to the items in SWEBOK that are not present in SA & D, specifically items #5 - #10. A major difference in the methodologies is the scope; SA & D is broad enough that it could apply to many process designs, not just software, where SWEBOK is much more focused on developing software. Since these are not covered in SA & D, let's briefly cover them:
- Software Maintenance
- This is basically what it sounds like: maintaining software after release. Included are requests for upgrades and corrections, along with the methods of tracking and logging such requests.
- Configuration Management
- Configuration management is the discipline of coordinating software, hardware, firmware, and versions of a program and how they interact at a given point in time, according to the SWEBOK website. When discussing maintenance of software at the level SWEBOK is concerned, this is as important as maintaining the code itself.
- Engineering Management
- #7 in the SWEBOK list is defined as "planning, coordinating, measuring, monitoring, controlling, and reporting—to ensure that the development and maintenance of software is systematic, disciplined, and quantified", according to the SWEBOK website. While this is seventh in the list of SWEBOK, it sounds very similar to #2 in SA & D. The largest difference, as far as I can see, is the placement within the methodologies.
- Engineering Process
- The engineering process is divided into two levels within SWEBOK: the managerial level and the detail level. Level one mirrors #2 in SA & D process, trying to manage the people and span of the project, where the second level focuses on the minutia of a project and measuring the effectiveness of the solution.
- Engineering Tools & Methods
- I'm a little surprised that this is a step, rather than a detail of working with software. Tools and Methods focuses on the development tools used in the design of a solution and the syntax and structure of the coding. This seems more like an overall guideline for a process, rather than an actual step to designing a system.
- Software Quality
- Once again, not really a step in a process, Software Quality is concerned with designing software such that the customer is pleased with the results. Specifically, quality in this area of SWEBOK is the techniques used to achieve and maintain quality as a standard practice across many projects.
There you have it - two different ways to design a software system. They are very similar in topics, and really only differ in the order of planning. SA & D is more focused on planning and control before design, where SWEBOK manages this aspect of design later in process.
Saturday, January 14, 2012
MIST 7530 - The Most Expensive Bullets
Hello again from CyberSpace!
It's a new semester, and that means time for more blog posts! The first installation will be about silver bullets and werewolves! Well, only metaphorical silver bullets and no werewolves...
The assignment was to read No Silver Bullet - Essence and Accident in Software Engineering by Frederick P. Brooks, Jr., which discusses the inherent difficulties in improving software programming, and the absence of 'silver bullets' that will advance programming by an order of magnitude, then come up with my own silver bullets, hypothetical as they may be. So without further ado, here is my top three list:
Silver bullet #1: Outcome Visualizer
Like a window into the future, this little gadget will accept a plan, detailed or otherwise, and show you that plan in action. You can see all the good your design creates, as well as any of the shortcomings. Using such a tool with help you to refine your designs, remove the most harmful pieces, and plan for the inevitable damage you will cause. TANSTAAFL; everything we do will surely have issues for the next project team to tackle.
Silver bullet #2: Specification Sniffer
Modern software programming environments, like Visual Studio 2010, have auto-complete functions which will assist the programmer by suggesting the correct function or property from the code. Intellisense, for example, will provide the most common option for the code being typed. Having a similar knowledge base for coming up with project specifications will assist in development. The system will go a step further by suggesting other similar actions, and even negative results associated with the recommended action. If a sniffer can help find common errors at design, the programming process becomes much simpler and more robust.
Silver bullet #3: Organic code
One of the largest issues in writing code is its static nature - the code you write can only do what it's told to do. There are techniques and styles to help reduce the issue, but the problem remains: code can't adapt on its own to changing demands and needs. If code could organically change or repair itself, we would actually need less system design, since systems would be able to grow and meet the current demands.
There you have it - three ways to help software develop as quickly as hardware. Even though none of them exist yet...
It's a new semester, and that means time for more blog posts! The first installation will be about silver bullets and werewolves! Well, only metaphorical silver bullets and no werewolves...
The assignment was to read No Silver Bullet - Essence and Accident in Software Engineering by Frederick P. Brooks, Jr., which discusses the inherent difficulties in improving software programming, and the absence of 'silver bullets' that will advance programming by an order of magnitude, then come up with my own silver bullets, hypothetical as they may be. So without further ado, here is my top three list:
Silver bullet #1: Outcome Visualizer
Like a window into the future, this little gadget will accept a plan, detailed or otherwise, and show you that plan in action. You can see all the good your design creates, as well as any of the shortcomings. Using such a tool with help you to refine your designs, remove the most harmful pieces, and plan for the inevitable damage you will cause. TANSTAAFL; everything we do will surely have issues for the next project team to tackle.
Silver bullet #2: Specification Sniffer
Modern software programming environments, like Visual Studio 2010, have auto-complete functions which will assist the programmer by suggesting the correct function or property from the code. Intellisense, for example, will provide the most common option for the code being typed. Having a similar knowledge base for coming up with project specifications will assist in development. The system will go a step further by suggesting other similar actions, and even negative results associated with the recommended action. If a sniffer can help find common errors at design, the programming process becomes much simpler and more robust.
Silver bullet #3: Organic code
One of the largest issues in writing code is its static nature - the code you write can only do what it's told to do. There are techniques and styles to help reduce the issue, but the problem remains: code can't adapt on its own to changing demands and needs. If code could organically change or repair itself, we would actually need less system design, since systems would be able to grow and meet the current demands.
There you have it - three ways to help software develop as quickly as hardware. Even though none of them exist yet...
Saturday, December 10, 2011
MIST 7500 Final Exam - Blog Post 6
Hello for the last time from CyberSpace!
That's right, this is the last blog post that will be made for this class. ;_;
Don't worry, though, as we have a great topic to go out on - Web Services! Web Services date back to the beginning of the century, as highlighted in this article (check the date), and are basically machine-to-machine communication over the web.
From Web Services and Service-Oriented Architectures
This communication leads to Service Oriented Architecture, where a programs are built from the ground up consuming data from a service provided over the Internet which isn't maintained or controlled locally. In previous decades, all the code in a program had to be housed within that program. Using SOA, someone else's code can be working to provide data to your application, reducing development time and leading to new possibilities. Maybe the code offered is something you couldn't have developed on your own, but with this missing piece, your program can finally see the light of day.
From ReadWriteWeb Cloud.
These services are typically provided by the use of APIs. APIs are web based programs that are set to common standards to facilitate machine to machine communication, making it easy for anyone to use in their programs. You can see by the graphic that the number of APIs is increasing dramatically just in the past 5-6 years. There are several dedicated sites for hosting APIs, such as apigee and Mashery, where you can find a plethora of APIs to meet your programming needs.
With the increasing usage of APIs and decreased development time, one might believe this is all roses. There are downsides to APIs, and one of the most aggravating is downtime. When you rely on someone else's code, which you have no control over, it is frustrating when issues arise. I am personally experiencing this currently while trying to publish the second part of the Final Exam on Amazon Web Services. After several individual attempts with no luck at launching a website, I did some research to find that Amazon was having issues with the east-coast server (mine). As of the time of this writing it is still not corrected, and my grade in this class depends on it. I am glad that I do not have my business website on this server; frustration doesn't cover losing money.
That does it for my MIST 7500 blog. I hope you enjoyed reading as much as I enjoyed writing!
That's right, this is the last blog post that will be made for this class. ;_;
Don't worry, though, as we have a great topic to go out on - Web Services! Web Services date back to the beginning of the century, as highlighted in this article (check the date), and are basically machine-to-machine communication over the web.
From Web Services and Service-Oriented Architectures
This communication leads to Service Oriented Architecture, where a programs are built from the ground up consuming data from a service provided over the Internet which isn't maintained or controlled locally. In previous decades, all the code in a program had to be housed within that program. Using SOA, someone else's code can be working to provide data to your application, reducing development time and leading to new possibilities. Maybe the code offered is something you couldn't have developed on your own, but with this missing piece, your program can finally see the light of day.
From ReadWriteWeb Cloud.
These services are typically provided by the use of APIs. APIs are web based programs that are set to common standards to facilitate machine to machine communication, making it easy for anyone to use in their programs. You can see by the graphic that the number of APIs is increasing dramatically just in the past 5-6 years. There are several dedicated sites for hosting APIs, such as apigee and Mashery, where you can find a plethora of APIs to meet your programming needs.
With the increasing usage of APIs and decreased development time, one might believe this is all roses. There are downsides to APIs, and one of the most aggravating is downtime. When you rely on someone else's code, which you have no control over, it is frustrating when issues arise. I am personally experiencing this currently while trying to publish the second part of the Final Exam on Amazon Web Services. After several individual attempts with no luck at launching a website, I did some research to find that Amazon was having issues with the east-coast server (mine). As of the time of this writing it is still not corrected, and my grade in this class depends on it. I am glad that I do not have my business website on this server; frustration doesn't cover losing money.
That does it for my MIST 7500 blog. I hope you enjoyed reading as much as I enjoyed writing!
Friday, December 9, 2011
MIST 7500 Final Exam - Blog Post 4
Hello again from CyberSpace!
This post is dedicated to Applications on the Internet and the way that they are made. There has been a lot of movement in this arena over the last decade.
Before we look at the types of Internet Applications available, lets examine the history of the Internet.
I'm not going all the way back to the ARPANET, just 2004 when the term "Web 2.0" was coined. The idea of Web 2.0 was that the Internet is moving from a storefront system, where users are only allowed to look at static pages, to a more in-depth and interactive system for people to actually use. To perfectly illustrate this point, Facebook first launched in 2004.
Ever since then, the trend in web usage has moved to interactive applications, giving users greater control over what they access and more opportunities to contribute themselves. My favorite example of interactive is Google Maps, an interactive map that can be used for all sorts of things. I get the most mileage out of Google maps (pun intended) when trying to get directions, but Google has added traffic, satellite images, and even business names to their maps, making for a very rich user experience. Something you may not realize, however, is that Google Maps is available as an API. This allows maps to be placed into other websites without any coding work on the web-owner's part. See the example below:
View Larger Map
I didn't code that, nor create the map, nor plot anything to the map. I just copied and pasted some code, and I have a rich, interactive map available in my blog. There are several other fantastic web apps available from Google, like Google Docs and Google Sites, but this isn't a sales pitch. Other examples of web apps include streaming video sites like Hulu and social media sites like Facebook and Twitter. Several web apps are not totally web-based and fall into the category of a Client Application, which require some sort of program download that requires an Internet connection to be useful. Probably the best known example of this is Skype.
Hopefully the myriad of examples here demonstrate the vast options of Web-Based Applications. It hasn't been slowing down since 2004, and doesn't show any signs of stopping.
Up next, we'll discuss the data behind all those web applications.
This post is dedicated to Applications on the Internet and the way that they are made. There has been a lot of movement in this arena over the last decade.
Before we look at the types of Internet Applications available, lets examine the history of the Internet.
I'm not going all the way back to the ARPANET, just 2004 when the term "Web 2.0" was coined. The idea of Web 2.0 was that the Internet is moving from a storefront system, where users are only allowed to look at static pages, to a more in-depth and interactive system for people to actually use. To perfectly illustrate this point, Facebook first launched in 2004.
Ever since then, the trend in web usage has moved to interactive applications, giving users greater control over what they access and more opportunities to contribute themselves. My favorite example of interactive is Google Maps, an interactive map that can be used for all sorts of things. I get the most mileage out of Google maps (pun intended) when trying to get directions, but Google has added traffic, satellite images, and even business names to their maps, making for a very rich user experience. Something you may not realize, however, is that Google Maps is available as an API. This allows maps to be placed into other websites without any coding work on the web-owner's part. See the example below:
View Larger Map
I didn't code that, nor create the map, nor plot anything to the map. I just copied and pasted some code, and I have a rich, interactive map available in my blog. There are several other fantastic web apps available from Google, like Google Docs and Google Sites, but this isn't a sales pitch. Other examples of web apps include streaming video sites like Hulu and social media sites like Facebook and Twitter. Several web apps are not totally web-based and fall into the category of a Client Application, which require some sort of program download that requires an Internet connection to be useful. Probably the best known example of this is Skype.
Hopefully the myriad of examples here demonstrate the vast options of Web-Based Applications. It hasn't been slowing down since 2004, and doesn't show any signs of stopping.
Up next, we'll discuss the data behind all those web applications.
MIST 7500 Final Exam - Blog Post 5
Hello again from CyberSpace!
How many Kilobytes did it take to post this page? Where is it stored? How long will it be available? How many more are just like it (I can think of 30+ similar posts) in the world? There is a lot to consider when thinking about the vast increase of technology usage in the world.
This blog post is dedicated to the data we create while living in a digital society. Data storage isn't anything new when you take a broader look at what data is and how it can be stored. Humans have stored data for thousands of years, including word of mouth and written records. Only recently have we begun to look at mechanical forms of data storage.
Check out the video below on digital data storage:
I thought it does a good job highlighting data storage mediums along with capacities. It can be hard to appreciate just how large a Terabyte is until you have a point of reference.
I'm sure we're all familiar with the more traditional disk-based data storage mediums, from hard-disks to floppy disks to CDs and DVDs. These all operate basically the same way - data is recorded on the disk, which is then spun across a reading device (an arm for hard-drives, a laser for CDs), which un-encodes the data for the computer. While there are several difference between the three mediums, they all work in a similar fashion.
The biggest changes in data storage options within the previous decade are Blu-Ray discs and Solid State memory. Blu-ray discs, a medium released in 2001 by by Sony, are the next generation of CDs and DVDs which offer upwards of 25 gigabytes of data storage. Typically used for High Definition movies, BD has firmly planted itself as the next-generation medium for high capacity storage.
The other option, Solid State memory, which moves away from the standard spin-and-read process of storing data. SSD uses microchips instead of moving parts, which increase the retrieval speed of the memory. These are very common, but in smaller sizes due to the cost of production, and most commonly found in Flash drives. Given the expense, however, they are slow to take over for the traditional hard-disks.
So, until we can write our memory on a grain of sand, we will keep spinning and micro-chipping our way into the past.
Look for the next and final installment in this exam assignment: Web Services
How many Kilobytes did it take to post this page? Where is it stored? How long will it be available? How many more are just like it (I can think of 30+ similar posts) in the world? There is a lot to consider when thinking about the vast increase of technology usage in the world.
This blog post is dedicated to the data we create while living in a digital society. Data storage isn't anything new when you take a broader look at what data is and how it can be stored. Humans have stored data for thousands of years, including word of mouth and written records. Only recently have we begun to look at mechanical forms of data storage.
Check out the video below on digital data storage:
I thought it does a good job highlighting data storage mediums along with capacities. It can be hard to appreciate just how large a Terabyte is until you have a point of reference.
I'm sure we're all familiar with the more traditional disk-based data storage mediums, from hard-disks to floppy disks to CDs and DVDs. These all operate basically the same way - data is recorded on the disk, which is then spun across a reading device (an arm for hard-drives, a laser for CDs), which un-encodes the data for the computer. While there are several difference between the three mediums, they all work in a similar fashion.
The biggest changes in data storage options within the previous decade are Blu-Ray discs and Solid State memory. Blu-ray discs, a medium released in 2001 by by Sony, are the next generation of CDs and DVDs which offer upwards of 25 gigabytes of data storage. Typically used for High Definition movies, BD has firmly planted itself as the next-generation medium for high capacity storage.
The other option, Solid State memory, which moves away from the standard spin-and-read process of storing data. SSD uses microchips instead of moving parts, which increase the retrieval speed of the memory. These are very common, but in smaller sizes due to the cost of production, and most commonly found in Flash drives. Given the expense, however, they are slow to take over for the traditional hard-disks.
So, until we can write our memory on a grain of sand, we will keep spinning and micro-chipping our way into the past.
Look for the next and final installment in this exam assignment: Web Services
Thursday, December 8, 2011
MIST 7500 Final Exam - Blog Post 3
Hello again from CyberSpace!
This entry is dedicated to the 'other side' of the Internet - Web Servers! Here, all the fun stuff we access on a daily basis.
The basic idea behind a web server is that they process requests from clients. In my previous post, I discussed how the client gets onto the Internet to find these web servers. Once the request is received by the server, they can generate HTML code, search a database, or other useful function, then return the data to the client. It sounds simple enough, but this can be a daunting task depending on the number of visitors to your site. For example, YouTube had 20 BILLION video views in October 2011! That isn't just generating some HTML, the web server has to find the selected video, stored in a database, then generate the "Related Videos" section, user comments... It can be daunting work for web servers to handle all the traffic without crashing.
Web servers can be split into several different layers for processing requests. This adheres to the principal of Separation of Concerns. The split makes it easy to update and maintain the code, and typically consists of Presentation, Business, and Data layers. There are other methods, but most follow this pattern. The reason for the structure is that it is easily maintained, so much so that it is a part of Apache Web Servers and recommended in Java EE Coding Tutorial.
Up next, we will look at the types of applications hosted on these web servers.
This entry is dedicated to the 'other side' of the Internet - Web Servers! Here, all the fun stuff we access on a daily basis.
The basic idea behind a web server is that they process requests from clients. In my previous post, I discussed how the client gets onto the Internet to find these web servers. Once the request is received by the server, they can generate HTML code, search a database, or other useful function, then return the data to the client. It sounds simple enough, but this can be a daunting task depending on the number of visitors to your site. For example, YouTube had 20 BILLION video views in October 2011! That isn't just generating some HTML, the web server has to find the selected video, stored in a database, then generate the "Related Videos" section, user comments... It can be daunting work for web servers to handle all the traffic without crashing.
Web servers can be split into several different layers for processing requests. This adheres to the principal of Separation of Concerns. The split makes it easy to update and maintain the code, and typically consists of Presentation, Business, and Data layers. There are other methods, but most follow this pattern. The reason for the structure is that it is easily maintained, so much so that it is a part of Apache Web Servers and recommended in Java EE Coding Tutorial.
Up next, we will look at the types of applications hosted on these web servers.
Wednesday, December 7, 2011
MIST 7500 Final Exam - Blog Post 2
Hello again from CyberSpace!
In this, the second blog of a six part series, we will discuss Internet Infrastructure.
The best way for me to describe the structure of the Internet is through a video. Feel free to watch below, but it isn't as short as the awesome graphics imply.
In case you don't have 13 minutes to watch, I'll summarize the video. Whenever you make a request on the Internet, you send data to your router. The router manages lost data, decides the paths to follow between servers, manages protocols, and other important tasks required to move to your requested location. Simplifying it down to this level is about the same as saying "Oh, you're just hauling rocks in that wheelbarrow", but that is essentially how the process works. The simplicity is not intended to downplay the importance of the router. Without it, we wouldn't have the Internet as we know it.
Packets and Routers have been around since the beginning of the Internet. The scale has certainly increased, and continues to increase thanks to the number of Internet connected devices. The increase is so rapid, in fact, that we have assigned all available IPv4 addresses. Imagine trying to active a phone for the first time, only to find out that we are out of phone numbers. Same idea, but with the your new Desktop instead. In response, IPv6 is now available, which should handle many more devices than its predecessor.
Once you fire up the ol' browser (a Client Application), get an IP address, and hook up with a router, you can be surfing the 'net in no time flat. Next blog we will examine the final destination of those browsers and packets - Web Servers!
In this, the second blog of a six part series, we will discuss Internet Infrastructure.
The best way for me to describe the structure of the Internet is through a video. Feel free to watch below, but it isn't as short as the awesome graphics imply.
In case you don't have 13 minutes to watch, I'll summarize the video. Whenever you make a request on the Internet, you send data to your router. The router manages lost data, decides the paths to follow between servers, manages protocols, and other important tasks required to move to your requested location. Simplifying it down to this level is about the same as saying "Oh, you're just hauling rocks in that wheelbarrow", but that is essentially how the process works. The simplicity is not intended to downplay the importance of the router. Without it, we wouldn't have the Internet as we know it.
Packets and Routers have been around since the beginning of the Internet. The scale has certainly increased, and continues to increase thanks to the number of Internet connected devices. The increase is so rapid, in fact, that we have assigned all available IPv4 addresses. Imagine trying to active a phone for the first time, only to find out that we are out of phone numbers. Same idea, but with the your new Desktop instead. In response, IPv6 is now available, which should handle many more devices than its predecessor.
Once you fire up the ol' browser (a Client Application), get an IP address, and hook up with a router, you can be surfing the 'net in no time flat. Next blog we will examine the final destination of those browsers and packets - Web Servers!
MIST 7500 Final Exam - Blog Post 1
Hello again from Cyberspace!
It's time for finals, and we're going to celebrate with marathon blog posts! In a series of 6 blog posts, I'm going to cover Client Applications, Internet Infrastructure, Web Servers, Applications, Data, and Services.
The doorway into any of these topics is Client Applications. These are the side of the internet most users are familiar with, as they are the part of the process users interact with directly. Rather than keeping all the necessary data on a local hard drive, these programs can interact with a server over the internet to display HTML code, gather data, or use a web service to produce the finished product.
A great example of a Client Application is the web browser you are using right now to read this blog. The browser itself doesn't contain anything particularly interesting on its own, but is able to translate HTML, JavaScript, and other code from servers out in the Internet to become much more than the humble program resting on your hard drive.
There are lots of options for Client Applications, and while the main player was web browsers five years ago, we are not as limited anymore. With the increasing number of web services and smartphones, there are more ways to consume data across the network that doesn't live in your device.
Probably the biggest change for Client Applications is the iPhone app. Despite being a device and not a Client Application, the processing power and limited storage, along with its almost-anywhere connection, the iPhone and its relatives rely on the internet to provide content. Apps on the phone may not hold anything substantial on the device itself, but can connect to the web or a web service to provide a great experience.
In a nutshell, the Client Application is moving to the forefront of computer usage. Stay tuned for the next entry in our series: Internet Infrastructure!
It's time for finals, and we're going to celebrate with marathon blog posts! In a series of 6 blog posts, I'm going to cover Client Applications, Internet Infrastructure, Web Servers, Applications, Data, and Services.
The doorway into any of these topics is Client Applications. These are the side of the internet most users are familiar with, as they are the part of the process users interact with directly. Rather than keeping all the necessary data on a local hard drive, these programs can interact with a server over the internet to display HTML code, gather data, or use a web service to produce the finished product.
A great example of a Client Application is the web browser you are using right now to read this blog. The browser itself doesn't contain anything particularly interesting on its own, but is able to translate HTML, JavaScript, and other code from servers out in the Internet to become much more than the humble program resting on your hard drive.
There are lots of options for Client Applications, and while the main player was web browsers five years ago, we are not as limited anymore. With the increasing number of web services and smartphones, there are more ways to consume data across the network that doesn't live in your device.
Probably the biggest change for Client Applications is the iPhone app. Despite being a device and not a Client Application, the processing power and limited storage, along with its almost-anywhere connection, the iPhone and its relatives rely on the internet to provide content. Apps on the phone may not hold anything substantial on the device itself, but can connect to the web or a web service to provide a great experience.
In a nutshell, the Client Application is moving to the forefront of computer usage. Stay tuned for the next entry in our series: Internet Infrastructure!
Subscribe to:
Posts (Atom)

