Welcome to the GrandBright Blog
Long time no blog, and iPhones for all the fish…
Posted on February 21st, 2010
Phew! Its been a long time since we updated the blog. Truth be told, our small band of developers has been hard at work both on the run up to the Christmas Season and well into the New Year. It was all hands to the proverbial grindstone as both development and management worked hard to bring a client into trial. After seven to eight months of hard server development they are close to going public, and with a solution that everyone is proud of. Not only is the base a solid foundation, but its a solid foundation from which growth of a company and a product offering can grow. More on this in time…
Other developers within GrandBright have been working hard on honing their handset skills. Historically GrandBright has been at the forefront of server development - providing highly scalable and robust solutions for clients that do ‘just what they say on the tin’. It seemed to us that in this day and age, where the smart phone is becoming more prolific, that we bit the bullet and started to learn a little more about how we could support these devices as a window into the server world. After all, on your average server solution you have a web page that provides a portal into the data (the ‘V’ in the MVC pattern). But with the advent of smart phones delivering rich applications there has been an interesting shift away from the thin web-client paradigm.
This is in reverse to the law of thin-client computing.
What Apple have done is create a new market - in the same way that they came into a market that was full of MP3 players and blew away the competition with the iPod, they have seemingly reversed the trend of web clients - at least for smart phones.
By installing an application on your iPhone a user can have a rich client into the server world of heavy data. Until web technology improves enough to give the same kind of user experience (and while this is a lucrative money making market) it seems like mobile ‘apps’ have a place in society. Once again the program that sits on the PC to access the server is back. Client-Server computing.
With this in mind GrandBright decided to endow itself with knowledge of at least one of the current technologies. We started a small department of developers that we financed to learn the ins-and-outs of iPhone development - perhaps the most successful technology that is available right now for mobile ‘apps’. With Apple’s structure and policing of the ‘apps’, as well as an amazing SDK and development environment, it seemed like the right place to start.
Our crack-team of developers (who had a history in embedded computing) took only a short while to become acquainted with the world of Apple - and how wonderful that world is for a developer. The structure of the iPhone SDK and the tools that are given away make it easy for a development team to start building another window onto a server solution. Bare in mind, however, that this technology also gives your development team the tools they need to shoot themselves in the foot. Just because the SDK and tools give accessibility doesn’t mean that a solution delivered is a good one, or of the quality required in order to grow and maintain a product over time. Our developers were tasked with learning how to write ‘app’ software with the quality that we expect on the server. This is no mean feet. Any developer can learn an SDK, but to learn the best-of-breed patterns takes time. Another reason why the blog has suffered.
So at last we can say that GrandBright is in the unique position of offering not only server and web development, but also iPhone development. This combination of ‘app’ and server is second to none in the industry. To understand both sides of the technology and have expertise in building a real end-to-end solution for these modern times is hopefully going to make GrandBright stand out from the crowd. Be sure that the quality that you see in our server development will be directly translated into the quality you expect for an iPhone ‘app’.
So where does the industry go and where do we follow? Predictions that Android could be on 20% of mobile devices by 2012 is indicating that we also look into Google’s technology. With the proliferation of mobile companies fighting to develop their own operating systems and platforms its going to be an interesting couple of years for sure. For GrandBright, I see that we will follow the trends in the near future so that we can provide our customers with the best bang for their buck in terms of consumer outreach. Coupled with the new version of the Blaze Web Stack we are hoping that the quality and service we provide will go from strength to strength, certainly in the coming year, and beyond.
Frameworks are like vehicular transport…
Posted on November 1st, 2009
Are your software architecture ducks in line? How does the framework you use differentiate itself from the rest?
Just today I was perusing the massive array of frameworks that are available for building software applications. Although I was specifically looking at Web UI frameworks, I noticed that it was possible to classify frameworks into many types. UI frameworks, middleware frameworks, database frameworks, frameworks specific for communications between SOA systems, frameworks for processing messages on queues, frameworks for easing RPC and communication between distributed databases. So many frameworks. And you can bet your bottom dollar that every day more are becoming available to confuse and confound software developers and their management.
One of the discussions on the Joel on Software Discussion Group really hit home to me some time ago. The story relates around a developer who needs to build an application. He researches into what framework to use as a basis and relates his findings to building a spice rack. To cut a long story short, our intrepid developer heads into a hardware store to buy the tools and finds that a simple basic hammer is no longer sold. No body really buys hammers as they are old fashioned and rather limited. The sales clerk goes straight to the ideal alternative: a universal hammer that does everything (rather than a claw, sledge, or ball-peen that are good at only one thing). As the sales clerk indicates, why buy one type when you are only going to find out you need another type in the future. And then we find the universal hammer is really old school too! Of course a universal hammer is adequate at doing all tasks, but not great at doing one. Instead the sales clerk tries to sell our hero a hammer factory - simply so he could make any type of hammer he wanted any time. And the story continues until we find out hero’s only option is to buy a ‘general-purpose tool-building factory factory factory’. Everyone is using one these days!
The author was showing that there are too many frameworks that do too many things for too many people in too many ways. A framework is like vehicular transport - they are designed to ease the journey to your destination but all of them have advantages and disadvantages. Much like a car, frameworks are geared toward a particular bias, and if they are totally universal then they do an adequate, but not great job. A two seater sports car is great for a young guy who wants to look flashy and go fast, but it serves no purpose for a family of mom, dad, and three kids. It would be quite a squeeze to get the family in as well as the beach towels when they want to head off on vacation. And young guy wouldn’t look quite as flashy, and certainly wouldn’t go fast if he drove the latest and greatest in minivans. General purpose utility vehicles are great, but if my hobby is off-roading they don’t really deliver the power I need and would constantly get stuck in mud or have the engine ripped out by jagged rocks and little ground clearance.
As a representative of GrandBright Software I have to tell potential clients why our framework, The Blaze Web Stack (oh no! not another one!), is different from anything else out there. This is truely a difficult nut to crack and as a developer I understand what it means to have to assess the pros and cons of frameworks, and then make an educated guess on which one to base my development-reputation on. For a business this is an even more important decision - often one that a development group is unaware of.
The Blaze Web Stack came out of a few needs that we saw as common requirements to a development. But what makes the Blaze Web Stack different is that the needs are based on delivery to the business and what the business needs, rather than cool technologies for the developer:
Simplicity.
One of the biggest issues that we come across when developing applications is that a great deal of time is traditionally spent away from delivering use case implementations for the business. Valuable time is spent on honing the environment or messing with configuration files or complex platforms that the developer doesn’t truely understand. There is often a slash-and-dagger or trial-and-error approach to putting software on an underline framework architecture. While the business logic may be sound the platform that the software sits on may not be. This can impact delivery, stability, maintainability, quality, and future extension of a product. One of the primary focuses of the Blaze Web Stack is to ensure simplicity for developers. You will always have to hone environments or configure platforms but it is important that each level of architecture is mutually exclusive. Many frameworks provide a universal hammer approach to their delivery, whether in terms of technologies utilized or architectual layers delivered. The Blaze Web Stack delivers only what it needs to fulfil the delivery of business-specific use cases to the customer.
Transparency.
ACID Transactions? Persistence using JDBC, POJO, JPA or Hibernate? Database Sharding? Configuration of environments? All of these things (and more) have to be taken into consideration during a development. But to keep delivery of use cases lean and mean you need to have transparancy between the business logic and the underlying technologies. The DRY principle of software development indicates Don’t Repeat Yourself - and transparency brings this principle to the forefront of the Blaze Web Stack. Common tools and patterns that we find are centralized and pushed into the framework. Platform specifics are pushed away from the developer and abstracted into easily usable concepts. Transparency blends into simplicity.
Adaptability and extensibility.
One of the key aspects of the Blaze Web Stack is its roadmap. In working with clients we find that there are key concepts that are common to businesses. Of course our clients keep their IP but we take common concepts not specific to the individual business and embrace them in our framework. This means that the Blaze Web Stack moves in a different direction than normal community-oriented frameworks. The business layer, not the technology layer, take a higher standing in our roadmap.
Philosophy and methodology.
In developing our business and our technology we have also discovered a philosophy of how software should be built efficiently and effectively. As developers we have put all the years of knowledge of what works and what doesn’t work into our methodologies. By adopting a sound philosophy a
nd sound software development methodologies we can deliver quality in smaller time frames than are usually expected. Philosophy and methodology and framework give an equation where the answer equals accurate and timely delivery. A framework can encapsulate more than just technology.
Developer Franchising.
I always wonder how a chain store produces an identical product from store to store. Take burger chains. Burgers flipped in Brussels are the same as burgers flipped in Anchorage. How? An individual who is granted a franchise to flip burgers in Hong Kong is given a set of processes and procedures by the owning company. These processes and procedures dictate an understanding of a way of doing things that will guarantee a known result. Now, the burgers flipped in Hong Kong are the same as the Brussels burgers. At GrandBright we follow a development philosophy based on a franchise. When a new developer joins GrandBright we share our processes and procedures so that the new developer will develop software in the same way as other developers. This franchise model is implicit in The Blaze Web Stack. Unlike other frameworks the Blaze Web Stack contains an end-to-end way of doing things. The GrandBright way.
Software is like Chess.
Posted on October 21st, 2009
When I was younger I tried to learn how to play Chess. I joined a local Chess club where grumpy old men used to sit around pushing wood on old boards. The Chess club was located in an historic church hall and every Friday hordes of people from all walks of life would go to do battle. Occasionally, the odd whiz kid would turn up and beat the grumpy old men that resided at the club like pieces of old furniture. Most often revenge would be handed back to the whiz kid in the games that followed. The whiz kid’s initial assumption of being the best Chess player in the club would evaporate as the grumpy old men collected pawn after pawn until the whiz kid was squeezed like a goat to a boa constructor. And after the first triumph of the whiz kid, no more would follow. You could see the concentration piling up on the grumpy old men’s eyebrows as they sucked on another cup of tea and put all their years of experience into yet another death-defying match against yet another hoodlum who was trying to lay claim to the number one board in the club.
For years I was haunted with how the grumpy old men could contort their old withered brains to out smart and out class the whiz kids. I went to college and I participated in university and Chess fell by the wayside.
But a memory of one game with one particular grumpy old man stood in my mind. I drew to play with the black pieces. My companion played white, and in doing so made the first move. He gained the advantage. I had seen this grumpy old man beat a whiz kid the week before and now it was my turn to be squashed and squeezed into a losing position. And this happened. The game progressed. I kept a beautiful pawn structure, my pieces were placed on what I thought were ideal squares. I was ready for the quick-fix-kill that would be the end of the opposing army. Now the time was ripe! The grumpy old man sucked on his tea. Scratched his head. Yes - I thought to myself - I was doing pretty good. Victory was in sight… and then a piece fell. And another. And another. A chain reaction of my pieces falling off the board had started. I lost exchange after exchange. There were no clear squares. No safe havens. Every twist and turn that my pieces moved in would be blocked then attacked.
The death of my army was swift. I left dejected. After such a great buildup, my empire had fallen. I was humiliated and my name had been chalked onto the whiz kid trophy wall of the grumpy old man.
Years have since passed and I have again picked up the books and started to teach myself how to bludgeon my opposition over the head with little bits of wood once again! But this time it seems different…
Instead of making spontaneous moves my pieces now have a purpose. Each one of them moves to his logical and ideal square based on (and here is the big secret)… a plan. The plan is generally simple, logical, and is dictated by the imbalances that exist on the board. Strong squares, weak squares, doubled pawns, isolated pawns, and other points of attack are created for a plan and by a plan. I still lose games, but now those games are more enjoyable, I have a purpose for my pieces, and I can try to steer the game in the way I want and take away the stress-inducing random moves than inevitably end up in spaghetti (see the previous blog regarding pizza if you want more incite into my food design epics)!
The parallel between software development and a game of Chess is quite surreal.
Planning in a business that wants to produce a software product takes on many aspects. There is a fuzzy set of unwritten planning-levels that reside between the macro and the micro. On the macro level planning of delivery around what goes to the customer and when. Sales and revenue, business growth, hiring of employees and retention of the same. Day to day running of the business internals as well as the business externals. On the micro level a single developer has to plan the structure of a single portion of software code and its life-cycle within a project. The CEO and the developer, so often at odds with each other are in fact intertwined on so many levels. One cannot exist without the other.
Like a good game of Chess, there is no quick-fix-kill in a business that builds a software product. A CEO that needs it yesterday can’t have it yesterday. Conversely you cannot draw out the game indefinitely, and a developer who wants to change the world in his own way and in his own time doesn’t have the luxury of a market that will wait for him. Building a software product or adding features to an existing software product takes team work and time.
At GrandBright Software we meet many companies who need a software product. More often than not bad planning on one level or another has caused them to end up with a product that is at best substandard, perhaps wrong for the market, or perhaps unworkable. Sometimes companies have great dreams but no resource with the right skills to make the dream a reality. Sometimes the reality is more of a nightmare than a dream. Sometimes a company doesn’t realize how important the correct building of their product really is - the importance of delivery of key IP, good design and coding, and maintainability. More often than not the development of the dream is left too late and the delivery cannot be made. Without the correct planning companies fall into the trap of realizing how hard it is to develop large scale software applications and before they know it they are burning money they don’t have trying to build a quick-fix solution.
Like a good Chess game - planning, timing, and execution will always deliver results. And this is where the GrandBright motto comes from - Build it once, Build it right. We don’t pull the wool over our customer’s faces - we work with them to provide the solutions they need. Above all else good planning is where it starts and good execution is where it ends, and we strive to make our timing impeccible.
Just what is a Web Stack?
Posted on October 4th, 2009
Just the other day myself and the other co-founder of GrandBright Software were conducting an interview for two developer positions that we have available. The two developers we were interviewing were extremely smart and very tech-savvy. On telling them about the Blaze Web Stack, one in particular (we’ll call him Sam for the purposes of this blog) looked very concerned. On questioning him about his quizzical look it transpired that he believed that the product in question appeared to be competing with some very sophisticated and well thought of open source solutions.
After some to and fro conversation with Sam (he understood our stance in the end), and a healthy discussion of the why’s and wherefore’s of our technology I sat down and analyzed what our company offered and why. What benefit was our technology over a competitor’s or an open source solution that appears to deliver similar promises? Why do we think that the products and solutions we deliver are as good as, or better than the products and solutions that other companies or the open source community deliver? In fact, in this day and age why would anyone want to invest in a solution built by another corporation as opposed to a free offering driven by a large community? It just doesn’t add up. Or does it?
First off let me say that I am personally a great believer in the open source community. In fact we leverage certain open source projects in the solutions that we deliver to our customers. I personally analyze deeply the source code released by these projects and I have for the most part been impressed with the quality and delivery of products driven by the community. These projects range from simple logging tools to fully blown UI frameworks. You can visually see the time and passion that has been put into many of these projects.
Of particular interest to this blog are the frameworks that sit upon application servers and enable organizations to build web-based applications. This was Sam’s particular concern. During our discussion Sam gave three of four examples of both open source and commercial products that appeared to deliver the same solution that our product does. In fact the differences are a little subtle and after some discussion Sam agreed that what we were offering was not in competition with these products but gave itself to be more complementary to a business - our offering actually put emphasis on the customer and the business needs as opposed to a developer and the development needs.
So who the heck is going to support me?
I’ve always liked to eat pizza. Just recently I have been working on cooking the perfect pizza at home. This task is actually not as easy as it may seem. I’m not one for mixing layers but last weekend I found myself with a problem. I constructed a (pretty large, and difficult to handle) 18 inch pizza with a fairly heavy topping made of layers of pizza sauce, peppers, chillies, tomatoes, ham, topped off with lashings of cheese. I spent at least twenty minutes creating my masterpiece. I was very cunning, and realizing that I had to transport the built pizza to the pizza stone that had been heating up in the oven, I had constructed the pizza on a metal pan that I had dusted with flour. My plan was to slide the pizza easily onto the hot pizza stone and there it would cook happily for twenty minutes - a perfect circle of food.
In principle my idea was right, but moving the pizza from its temporary construction site to the stone proved to be my downfall. I had inadvertently chosen the wrong platform to build my pizza on - the flour had absorbed some moisture and the pizza had bound to the surface of the pan proving impossible to get any form of sliding to happen. It took two people to unbind the pizza and scrape (not slide) it onto the stone. The result was a mess of mixed layers - of tomatoes below cheese, peppers above tomatoes, and ham on the pizza bottom. Not to mention the pizza was no longer circular, but oddly elongated - the balance of food placement and symmetry had been ruined.
GrandBright Software provides a set of layers on which our customer’s can build a pizza of their choice. Put it another way - to build software that is maintainable over time you need to be able to control your layers so they don’t get mixed up and confused.
The most important aspect of what we deliver is a foundation on which your pizza of software can be built. This foundation is rock solid, providing important services for allowing our customers to build their business logic (tomatoes and ham) and keep them where they need them for maintainability and stability over time.
This weekend I built pizza again. My foundation was a non-stick metal pan. My pizza was circular, tasty, and all the layers remained in their place during transportation to the pizza stone. And this is one of the keys - GrandBright Software’s non-stick solution is based around the fact that we hold our customer’s business and what they want to do above all else. The focus is on the business and not the developer. We want the business to deliver its toppings in the best way possible, and not to have its business compromised by sticking to the pan on delivery. As a business you shouldn’t be focused on technical issues that stop you getting your solution to market - you should be focused on delivering what your customers need, without compromise, as quickly and as cost effectively as possible. You just don’t have time to let your developers unbind the pizza in the hope that it turns out right.
Unfortunately the truth is that many solutions available on the market today are based around technologies. They support many technologies on a single platform that a business just doesn’t need in order to get its product to market. Important ideas and principles for a business are ignored (such as simplicity, maintainability, scaling, minimal configuration, patterns for implementing business logic) and secondary, less important developer centric mechanisms are supported (technology a, b, and c - most of which will never be needed in the project anyway, and some of which complicate delivery beyond comprehension).
Sell me what I want, not what you want!
The investment in developing the Blaze Web Stack includes training of our development staff to understand not just our technology, but also the GrandBright philosophy. As founders of GrandBright Software, we have spent years making really bad pizza - or rather software. Its a difficult admission to make but its one that every single developer should make - because in order to build a good pizza you need to learn from your mistakes. There is no other way. The positive lessons learned from our mistakes have been driven into our Web Stack. Our solution is not based on what technology is in vogue now, and what technologies may be exciting to use or good for our resume’s or interest. Rather, it is based on a deep understanding of what a customer really needs. This is presented through our software, our methodology, and our development staff who understand the GrandBright way.
Effective Scaling for Enterprise Systems
Posted on August 26th, 2009
When building an Enterprise level web based application, be it a web site or business application, an organization may need to support an unlimited number of users. Most organizations do not realize that without the appropriate technology incorporated in the system design from the very beginning, their system could fail before they even get a chance to increase the user base.
The result of missing this crucial step will most likely cause the organization to redesign and rebuild of the entire system at the point where the application is starting to grow at an exponential rate. This could cost a significant amount of time, effort and money and potentially end the life of the system.
The umbrella term necessary to avoid this potentially destructive result is called scaling and encapsulates a number of technologies.
What is scaling?
Scaling is the ability of a system to enable an unlimited user base resulting in unlimited growth.
It applies to multiple levels of any enterprise level web based application. Application server (Load Balancing), database server and file system.
Two types of scaling are defined for our purpose. Vertical and horizontal scaling.
Vertical scaling is the traditional way a system grows. A single server is used to handle the user database and file system. As the user base grows, so does the size of the database and any files stored on the file system. Once the system starts to reach a saturation point, more hard drives, CPU, and memory, are added to accommodate this growth.
The problem with this scenario is that you are still dealing with a single server which is limited by the size of its resources - the fact that a single server can only process so much information before performance is degraded to an unsatisfactory level should cause concern.
Vertical scalability is suitable for small systems where the growth of the application is guaranteed to be to a limited user base. You may not even be able to classify such a system as enterprise level.
Horizontal or enterprise level scaling is the ability of a system to grow to accommodate an unlimited user base and unlimited number of servers.
Lets break up horizontal scaling into it’s different components.
Application level scaling or load balancing.
This is the ability of a system to accommodate multiple application servers all doing the same job. The job is to process information. No storage is done at this level. The user logs into the system and is directed for that session to a specific application server. Of course this is transparent to the user, but crucial for system performance.
Lets say we have 5 application servers in a cluster. Every time a new user logs on, the next server in the cluster is used. Of course there are many different ways to load balance, but for this blog post, we are going to illustrate using the round robin method. DNS is used to allow each server to be accessed in sequence. Each time a server is accessed, it moves to the bottom of the stack and all the others move up.
This enables the efficient processing of requests in the cluster. Performance is monitored in the cluster and as it starts to degrade, more application servers and more sophisticated techniques can be applied to determine which server is used. Of course once the cluster reaches a saturation point, another cluster can be added and each cluster is in turn load balanced. Interesting architectures for scaling now belong to the network level where blocks of servers or subnets can be introduced into the scaling model.
Your user session will contain information on which database and file system server you are supposed to be talking to, but this will be defined in the next few paragraphs.
Database scaling
Now that we have our application load balanced, the next task we face is to be able to handle unlimited users to be stored in our database. At a certain point, the performance of the database server will degrade to an unsatisfactory level. The number of users a database for a particular system can handle should be ideally determined up front, although this is changeable over time.
How do we scale and spread our database across multiple servers? Most modern databases have a concept of database shards. Simply put a database shard is a small subset of the entire database. A single server could and should consist of multiple database shards. Each shard will contain multiple users. Say we have 1000 users per shard, and 10 shards on a server. This gives us 10000 users stored in the database for that server. Remember, we are not talking about the file system here, only database storage. Large files should never be stored in the database for performance reasons.
Depending on the system, it may not be advisable to have a single server with a single database shard - although this is a very viable architecture. Some systems can perform better with multiples of both. Primary key control is of paramount importance, and for a simple scenario a shard could have it’s primary key sequence start where the previous shard primary keys ended. A process for primary key control has to be determined and designed up front.
Design of scaling systems is crucial to the success or failure of the entire application and possibly business as a whole.
Data needs to be assigned to a specific shard, splitting the domain model at appropriate points to ease querying - particularly where joining over multiple shards could occur (this kind of querying can be tricky). A strategy for splitting data can be determined by the designer of the system. For example, when a new user and his related records are added to the system, he is added to a specific shard. When the user logs on, an algorithm or a look up (perhaps on a central database) will figure out which shard his information is stored on - application server routing to this data can then occur. Keeping related data together simplifies the querying processes.
To sum it up
Scaling is not something we want to start after the design phase. This is an integral part of the system design, just like any other critical design piece. Scaling is also largely dependent on network infrastructure as well, and can also be built in stages as the system expands and grows. Your system does not need to be designed to handle millions of users from day one, but if your scaling infrastructure is in place, you can change as your business needs change.
Failure to effectively design scaling into a potential enterprise level application is a huge mistake made by many organizations. This happens mainly because of lack of knowledge and insight. Some of the most popular web based application vendors in the world failed to address this crucial issue when building their applications, and have no doubt caused the end of organizations before they even start.
My CSS Float’s don’t behave themselves…
Posted on August 17th, 2009
One of our developers (we’ll call him Bob) recently worked on a Web Application for a client where he had to float HTML div elements within other div elements. This hierarchical combination of divs produced a reusable panel component that the development team could use across many pages.
In order to abide by web standards and move away from creating his panels using tables, Bob decided his panels would contain two floated divs - one on the left and one on the right which in turn would sit inside a containing div, allowing him to add beautiful CSS styles that could be applied across the whole component.
Unfortunately Bob didn’t fully appreciate the rules governing how floats behave, and he got very frustrated that containing divs kept shrinking and the surrounded content didn’t end up where he thought it would. This caused Bob hours of anxiety and he cursed all the browsers for having bugs. However, flow of content around floated elements in containing divs works this way as specified by the W3C recommendations (for an in-depth look at the float rules, see their Visual Formatting Model). 
This HTML shows a simple containing div holding a left div and a right div (for Bob’s sake we will call these panels). These child panels together with their container constitute the layout of Bob’s panel component.
The CSS positions each panel with a fixed width, some padding, and a color to differentiate the content and illustrate our point.
When rendered by the browser, the left panel will display above the right panel (Bob didn’t apply the floats yet so he expected this) and were housed by the container div in the manner Bob guessed. Take a look at the diagram below. The left hand image shows what Bob saw. The next item on Bob’s list was to float his child panels. He did this by adding float:left to the leftPanel CSS and float:right to the rightPanel CSS. This was the start of Bob’s headaches.
What Bob saw is shown here in the middle. His panels are rendered side by side but his container has shrunk down. It took Bob some time to realize he had a problem because he didn’t apply a background color to his container and carried on merrily on his way. He had build around five types of panel when he started to style his containers and got the shock of his life. Bob spent several days trying to understand why he was getting this problem (”Ah he though - perhaps its an IE bug… although the same behavor can be seen on Firefox and Chrome! May be they all have bugs”). Unfortunatly Bob didn’t control his urge to fix the problem without proper research and ended up hacking away at the HTML and CSS, inserting styles and blocks that seemed to help without knowing whether they were really a good solution.
After some days of frustration Bob eventually turned to another GrandBright developer (we’ll call her Marge) for advice. Marge was well known for her knowledge of web development and she indeed had some answers for Bob. The result of these answers was that Bob quickly got the panel he always wished for. Marge helped him tidy up his code, Bob got his panel completed (see the third image in the diagram above), and the customer got his delivery on time.
So what did Marge do?
Marge explained to Bob that you can force a containing element to contain its children (and not shrink) very easily. It was just a matter of which method you choose. You have to force the container to behave differently to the way that W3C say it works, but that’s okay because you know what you want.
The first method Marge suggested to Bob was to use a clearer div. This is a standard method which simply means adding a div element as the last element in a container and setting its style to clear:both. The diagram on the right shows this.
Of course you would probably put the style into your CSS but I didn’t want to have to put that image in here as well so for clarity I have just used a style tag.
As Marge explained to Bob, this method is really fine, however the markup purists don’t like it because it requires an extra element to be put into the markup (read: markup bloat). The whole point of CSS is that it allows you not to require markup for styling so you should look the other way if you use an extra div like this.
There are one or two pseudo-classes that can be used to good affect for clearing the div but cross-browser problems can occur because they are not completely implemented (IE is known to have problems).
Marge explained that another acceptable method for getting the container to wrap its children is to float the container as well. Simply apply a float:left or a float:right to the container and it will expand to fit its child elements. You’d have to remember to clear any element immediately following the container in the HTML and you’ll have to explicitly specify the width of the container. Marge explained to Bob that if you float an element without specifying the width strange things can occur during rendering.
There was one last method that Marge explained to Bob. Simply add an overflow:auto style to the container element. The more modern browsers support this style so if you don’t care too much about supporting older browsers this is also a way to go.
Bob decided to stick with the overflow:auto method as his client was only concerned with supporting modern browsers and getting his product to market - his target audience were not legacy IE5 users, for example. Its nice to see Bob walking around with a spring in his step now he knows how to build his panels quickly and easily and without all the headaches he had in the recent past!
Introducing the GrandBright Weblog - bringing our people to you
Posted on August 16th, 2009
GrandBright Software Inc has decided to join the millions of users on the Internet that blog their thoughts. It seemed prudent for us to reach out to our customers and bring some of our thought processes to the public. What you will find in this blog are the thoughts and ideas on development, processes, methodologies and principles from our in-house experts, that are enabling GrandBright Software to become a key player in delivery of quality solutions for our customers.
