Updates from June, 2005 Toggle Comment Threads | Keyboard Shortcuts

  • wade 16:50 on Tuesday, 28 June 2005 Permalink | Log in to leave a Comment  

    Phlyte meeting, June 30 

    Our third official Phlyte meting will be held on Thursday, June 30th, at the usual Salt Lake City location at Code Greene in Foothill Village. Everyone interested in the project is encouraged to attend.

    The goal is to continue to make the important decisions and to get started actually writing some code this week. We’d like to cover directory structure for the site, coding style standards, and some basic guidelines for what code belongs in which files.

    After the meeting is over, this article will be updated with links to an audio recording, if we can get one, and a meeting report with a summary of the decisions we made. Don’t forget to use the #phlyte IRC channel and the Phlyte mailing list, too.

  • Jacob Wright 19:24 on Monday, 27 June 2005 Permalink | Log in to leave a Comment  

    Planning systems (3 of 5) 

    Object-oriented programming gives us many new ways to create an application. It makes many things easier to do. One of these things is planning. Planning is an important and oft overlooked part of an application, but it is as essential to the success of the application as the coding of it. Just to clear the air, let me clarify that planning is not necessarily spending months of sketching diagrams before a two week project. Neither is it coming up with things as you go. But planning is a great tool that will make applications more solid, easier to build, and quicker to build.
    Four Story Lean-to

    I spent some time in other places of the world. One of these places was Malaysia, great country. During my visit I traveled to many of the poorer areas of the country and one particular community stands out in my mind. In Tawau, East Malaysia there was a whole subdivision of houses built out over the ocean on sticks. The houses were shacks, built with driftwood and covered with tin. The walkways between the homes were also driftwood and just nailed together in random fashion. Being five times taller and three times less skinny than the largest man there (maybe that’s an exaggeration) didn’t make me feel any more comfortable walking around out there. It was obvious there had been no master plan, no idea of how the houses would be put up. But hey, it saved on property taxes.

    These homes were not built to last, nor would it be easy to add new homes to the community or upgrade existing homes. And there was definitely a lot of upgrading that could have been done! Similarly, if we try to build mansions of sticks, four story lean-tos, or even a modest home with no plan, our applications will end up looking (and working) more like the forts and tree houses my brother and I built in the field behind our house.

    I think all of us have built applications like this and know the pain and the bugs and quick-fixes that need to be made for the application to even work. Even after that it doesn’t end up being something you are proud to show to others (unless, of course, it’s one of your very first applications, in which case it is amazing that you got something to work at all and you want everyone and their grandmother to see)

    In addition to giving us a nicer product in the end, planning allows us to ‘share the wealth’ with other programmers, so to speak. We are able to help everyone see the master plan and their part in it. We are able to have more than one developer work on it at a time. Pretty innovative idea, I know.

    So how should we plan? However we want. You don’t need to use UML to plan. You don’t need systems design and analysis training. You just need to sit down with some paper and start writing (or drawing) an idea of how the application will fit together. You could even just take a moment to think it through without any writing utensil for smaller projects. We will go over how to organize, what to reuse, and what we should use while we do it (our brains).


    The definition of organize as Google’ tells us is ‘formed into a structured or coherent whole; methodical and efficient in arrangement or function; arranged into definite structures.’ We need to know where things are, where they are going to be, and how to find them. We also need to know how they are going to work together. Object-oriented programming is great for this because it give us a way to plan called object-oriented design. I discussed in the previous article Thinking Object-Oriented how we can visualize systems in terms of real-world objects. This is what object-oriented design is aimed at doing. We plan out the system modeling it after the real world. We imagine our ecommerce store is a real store and plan out the system based off of how a real store works. We think of our intranet as it were the company’s actual organization and plan it out into departments with their managers and employees. We are able to plan a system much more easily because we live in the real world (well, most of us anyway) and are familiar with objects, items, things, and stuff in our everyday lives.

    When we create an object we need to consider that is might be reused elsewhere. This means that it shouldn’t rely on system specific things to work, and if it does, there should be a known (and good) reason for it. This kind of separation from the environment is called encapsulation and is an excellent way to make an object reusable, as well as easier to maintain and update.


    I don’t know how many times I’ve heard ‘let’s not reinvent the wheel,’ but it’s been a lot. Many times it’s been with valid points. Many other times it hasn’t been. Let me first explain what we should reuse (and shouldn’t) then I’ll go over why object-oriented programming allows us to reuse code more easily than procedural programming.

    What is a classic example of something that uses a wheel? A car. Do we ever use a wheel by itself? Not often. When we ‘reinvent the wheel’ we are recreating something that has been done by many others before. However, I would like to emphasize that it is not creating a custom application again. A car is made up of many reusable parts, but we cannot take an economy car and make a four-wheel truck with it. We should build applications with reusable parts, and if our new application is to be the same or similar to another, then we can take the old and tweak it up a bit, give it a new paint job.

    The reason why I am even going over this is because of many bad experiences in the past. It seems many development teams want to try to take an existing system and create their own custom application with it. ‘Why reinvent the wheel?’ In every instance it has taken much longer to try to integrate with the existing database, to try and force the application into strange contortions, to try and add ‘a few additional features’ (which end up doubling the features) then it would have been to step back, plan out the system from scratch, and rewrite it from scratch (hopefully reusing many _parts_ or pieces of other applications).

    Ok, enough with that. Why is object-oriented programming more reusable than procedural? Well, again it goes back to things being easier to think about. If you are looking to put a stick-shift into your new car, you ask for a stick-shift and you get a stick-shift as well as all that goes with it. You’ll get the numbers of the gears, the methods to shift and put into neutral, all of it. If it were procedural you would need to get each method separately (although they may be sitting next to each other) and make sure you don’t forget what and where the properties are. If you need a customer in your store you could grab it from another store. You don’t need to search for all of the parts scattered throughout the store. In addition, if you need to change the customer, you only have one place to do it. And again, it’s much easier to think about the system as objects and how you might reuse the parts.

    It is much easier to find things in an organized room, and object-oriented programming provides greater organization for an application than procedural programming.


    Now, many who are weary about using object-oriented programming are such because they have seen horrible programming that used classes, methods, and properties. They feel their procedural programming is ten times better, and they might be right. Object-oriented programming is no magic hack. It is not a cure-all. No matter how we program, to make good programs we must use your brain. I know, I know, it sounds like too much to ask. Actually, I think all of us know we may write code without much forethought of how it needs to work or turn out. We often can make it work too, just not as well as it should.

    We must think about where we are going and what we are doing when we program. Even if we don’t have a written plan, we need to think the system through before hacking away. Thou shalt not be mentally lazy is a commandment I give to us all.

    I wish us all luck as we build our mansions or high-quality single family homes. If we are committed to planning we will end up with nice products in the end.

  • thebigdog 4:00 on Friday, 24 June 2005 Permalink | Log in to leave a Comment  

    UPHPU Eclipse Linux release 

    If you have been lurking on the #uphpu irc channel then you have probably heard me talking about the eclipse IDE with others and especially the arch enemy of it, dataw0lf.


    However, in the spirit of friendship I have create a special version of eclipse for linux gtk that has removed all the java libraries and have replaced them with Colorer, PyDev, Ruby-eclipse, and Perl EPIC. Basically, I stripped out all the excess and put in the killer stuff. I also added FTP and WebDav support, CVS support, and SFTP support. This IDE will allow you to manage multiple projects and in various languages, not to mention it is half the size it was. I will be writing up some articles on how to use UPHPU Eclipse for PHP and other development like Python and Ruby. If you have heard me talk about eclipse and want to give it a try you can download it here. I will be adding a windows and mac version to when time permits. If you run into any issues or would like too added some additional plugins like subversion or c/c++ then shoot me a message on the #uphpu channel.

  • wade 19:01 on Wednesday, 22 June 2005 Permalink | Log in to leave a Comment  

    PHP vulnerability containment 

    A new security magazine called [in]secure has just come out with their second issue which includes a pretty good look at PHP vulnerability containment within a shared server space (page 26). Has some good examples and is a good overview-type read.

  • wade 19:26 on Tuesday, 21 June 2005 Permalink | Log in to leave a Comment  

    Basic Linux network security, troubleshooting and tips 

    For our June meeting, Ray Hunter and Joshua Simpson gave an excellent presentation on basic Linux network security, troubleshooting & tips. They taught us a bunch of useful things about firewalling, PAM, SSH, Linux boot/startup, and configuring Apache.

    Download the presentation slides from Ray and Joshua.

  • Jacob Wright 15:34 on Monday, 20 June 2005 Permalink | Log in to leave a Comment  

    Thinking object-oriented (2 of 5) 

    This is the second of five articles written on object-oriented programming. These articles were originally written for jacwright.com This article was going to be entitled Conceptulizing Systems, but was changed to Thinking Object-Oriented as this title better describes the content of the article. I hope these are of benefit to you.
    Real Power

    One of the more difficult jumps of the several leaps and bounds from procedural to object-oriented programming is conceptualizing the system you are programming. Thinking object-oriented is the real power of object-oriented programming, and even if we always program procedurally we may already be thinking object-oriented. We need to be able to see a system, a problem, or a program in terms of objects and their relationships to one another. When we do this any program will be much more simple and easy for us to grasp. It will be easy to picture how it works in our minds.

    There are three ways to think object-oriented. One way it not better then another. They are all just different and each of them is used as we start use objects appropriately. I call these three ways the Top Down approach, the Bottom Up approach, and Real World Modeling.

    Top Down

    The Top Down approach in object-oriented programming give us a way to see the system as a whole. We break the entire system down into related parts. The Model-View-Controller design pattern (we’ll talk about design patterns in a later article) is an example of this. It breaks the system into three parts: objects related to the business model, display objects, and objects to handle user input.

    When we use the Top Down approach we need to think of how the system can be broken up into logical pieces. We can slice up the entire system like I do a pie. First I slice the pie in half, then in half again, making four pieces, then in half again. I end up with nice evenly sized pieces, something I’ve never been able to do by slicing a piece at a time. Similarly with a program or system (which might be a small part of a larger system) we break it up into larger pieces, then smaller ones, then even smaller ones, until we have pieces of a manageable size.

    We can see the Top Down approach thinking with a short example. Let’s use the oh-so-common ecommerce store. If we think of the system as a whole we know there will be data to keep, store functionality, and a good looking design that we want to change once in awhile. We can break our data section down into session management and a database object. We might break our store functionality into sections like the catalog, product reviews, the shopping cart, and the checkout. We can have our display section broken down into a general template and a caching template that will cache pages for reuse (so the database doesn’t have to work so hard). We can then go over each of the functionality sections and further break them down into small pieces and objects.

    Bottom Up

    The Bottom Up approach does not look at the system as a whole. Instead, it concentrates on grouping related functionality together. We see functions and variables as related and so put them together into an object. Then we see objects which interact or are related and put them together into a group (called a package, usually put into the same folder etc.) We can then group those object groups into larger and larger groups until we have the whole system accounted for.

    Using this approach to think object-oriented we use two different steps. The first step is grouping functionality into objects. The second step is grouping objects into groups. For step one, we figure out what goes together. This can be easy if we already group our related procedural code into files. We may have a file that contains all of our database functions in it. Instead of having all the functions there sitting in the global scope and the variables they use (perhaps a connection variable, or a record-set variable), we can group it all into a database object, with properties such as the connection reference and functions such as query or closeConnection.

    The second step is similar to the Top Down approach, just backwards. Instead of breaking a system down into parts, we are building it up from the pieces we know we will have. Grouping objects into larger and larger groups until we have the whole system makes it much easier to picture the internals of a system in our mind, and how things are actually working. It also allows us and others to easily find pieces of functionality to extend or fix because they are organized into folders and files (packages and objects) in a logical manner.

    Model the Real World

    Finally, Real World Modeling is one of the most powerful aspects of object-oriented programming. This is making objects that you know in the real world into objects in your system. Because we all live in the real world, it is easy for others to immediately understand what an object is and does if it is based off of something real world.

    A customer, shopping cart, and product in an ecommerce store are immediately recognized and their interactions between each other are understood easily, because we can see the same interaction in our daily lives. We know that there can be many products in our shopping cart. We know that each customer may have a shopping cart to put their products in. We know that customers have names and addresses, and that products have names and prices. The programmatic shopping cart however may have related functionality that a real shopping cart may not have. It may be able to tell us the total price of all the products in it, where a real cart can’t do anything but roll around (something not needed in an ecommerce store).

    The first thing you might do when developing a system is to discover all the real world objects in that system. Whether it is employees, supplies, offices, text characters, documents, buttons, or trash cans, they all help us think of the system easier and model it better. We already know many of the objects’ interactions and who “owns” what (the customer owns the shopping cart and the cart owns the products). These real world objects may even be the groupings of objects instead of the objects themselves. Or they may be objects that help group others. You might have a department object with its employees and manager.

    Once you have the real world objects you can then group them. The shopping cart, order, and checkout might go into the same section. You may put products and categories into the catalog group. Customers and store admin may be their own group.

    Object-Oriented Thinking

    Object-oriented thinking has been around even before object-oriented programming. People do it without knowing it might be called object-oriented. It helps us conceptualize a system and better grasp it. It helps us wrap our mind around a system without blowing a fuse. It makes programming easier for us and easier for others coming to our code. Object-oriented programming was created to make it easy to transfer our object-oriented thinking into code, although we can still program procedurally our object-oriented design. This is the real power of object-oriented programming.

  • wade 19:17 on Wednesday, 15 June 2005 Permalink | Log in to leave a Comment  

    Announcing the Phlyte framework project 

    Our group project to build a framework finally has a name: Phlyte (pronounced like the word “flight”). It emphasizes the goal of our framework to be lightweight, not too complex, flexible, and easy to use.

    I would invite anyone who is interested to subscribe to the new mailing list. Our in-person meetings that will occur probably 2-3 times per month are important, but not strictly required. Participation in the IRC channel at #uphpu or #phlyte on irc.freenode.net is highly encouraged. Subscribing to the mailing list is pretty much required.

    A big part of Phlyte development will be about teaching each other how to be better developers, especially with PHP (and Python, for those helping with the Python version of Phlyte). Most of this will happen in the meetings and in team meetings, so it is important that everyone participate as much as possible.

    Thanks to everyone who has participated so far, and I look forward to working with each of you more in the future!

  • Jacob Wright 22:11 on Monday, 13 June 2005 Permalink | Log in to leave a Comment  

    An introduction to object-oriented programming (1 of 5) 

    This is the first of five articles on object oriented-programming from Jacob Wright.

    • An Introduction to Object-Oriented Programming
    • Conceptualizing Systems
    • Planning an Application
    • Creating Objects
    • Making Objects Reusable

    An Introduction to Object-Oriented Programming will give a brief overview of why there is such a thing as object-oriented programming. Conceptualizing Systems will help us to better picture a system in terms of objects and how the relate to each other. Planning an Application will teach us the importance of planning and what we should do to plan. Creating Objects explains how the objects in our application are born, and how they should be structured. Making Objects Reusable covers some more advanced topics and allows us to reuse what we�ve already created in good ways. My hope is that these Monday morning articles will help others through the transition from procedural programming to object-oriented programming.

    Why Does Object-Oriented Programming Exist?

    Back in the olden-days, way back when our dinosaurs were young and our parents roamed the earth, there was programming. Yes, hard to believe it was invented by that time. Back then, things were simpler. Maybe people had to walk uphill both ways to school then, but programs were smaller, less complex. Programming languages executed line by line. They had �go-to� statements that let them go to another line for execution, and that was nice, but they didn�t need a whole lot anyway.

    Industrialization came along however. Change was happening. Programs became more complex. It was hard to wrap the mind around a complex program and write it line by line. Procedural programming was born. Procedures or functions allowed a programmer to more easily conceptualize a system. It allowed them to reuse code. It was easier to program.

    Object-oriented programming (OOP) came about the same way. When programs became larger and consequently more complex, it became very difficult to wrap one�s mind around them. Object-oriented programming made programming a system easier. It made life simpler again.

    Function, Function, Who�s Got the Function?

    Many times procedural programming is referred to as �spaghetti code.� Why is it called spaghetti code? Because there are functions being called throughout the system and we can�t know where they are coming from. If we follow the flow of a procedural program, we can find ourselves looping in and out of functions and throughout scripts very much like a bowl of spaghetti. There is not (inherently) much structure. There is not much organization. Object-oriented programming becomes more like building blocks we can build with instead of spaghetti. It provides organization and we can know exactly where a given function is. This also makes it easier to know where a bug is coming from.

    What Does Object-Oriented Programming Allow Us To Do?

    Object-oriented programming allows us to reuse code. It gives us a �package� of related functions and their related variables that we can pass around or reuse in other systems. These functions and variables that are all related are called methods and properties in an object. Object-oriented programming can also enable the use of complicated code by everyone. It not only ports the methods and properties together, but also allows us to use them without figuring out how they work internally.

    When Should We Use Object-Oriented Programming?

    Object-oriented programming was conceived to allow us to create larger projects more simply. Thus, it is very helpful in our larger projects that we do. I can also be nice in smaller projects, especially once we get the hang of it. Small projects are easily done in procedural programming though, and even once we learn how to program object-oriented we may still find ourselves using procedural at times.

    Is it ok to mix objects with our procedural code? Of course! Many feel that if they are going to program object-oriented that they need to jump into the deep end and just start swimming. That is just not true. It would be much better to start using objects bit by bit, more and more, than to just not use them at all because we feel that it is too much for us. Also, for small scripts it may just be easier to do them procedurally.

    So What Is Object-Oriented Programming?

    Object-oriented programming is a way to think. To conceptualize a system or a program. It is not the classes, syntax, encapsulation, or other big words that we will learn about in following articles. The true purpose of OOP is the empowering it gives us to see our programs in a new light, a higher view, a clearer picture. It is hard to go back once you�ve had a taste.

  • wade 21:04 on Thursday, 9 June 2005 Permalink | Log in to leave a Comment  

    Phlyte group project meeting, June 9, 2005 

    A recording of the successful group project meeting held on June 9th is now available as a 2-hour OGG file, weighing in at about 43MB.You can download it here.

    The next Phlyte meeting will be held on Thursday, June 30, 2005, at the usual Salt Lake City location in Foothill Village, along with food and beverages before and/or after the meeting for those interested. (BYO$)

    (The project was officially named Phlyte since the meeting was held, though the name was discussed there.)

  • wade 15:44 on Wednesday, 8 June 2005 Permalink | Log in to leave a Comment  

    10 years since PHP 1.0 was released! 

    Happy birthday, PHP! It has been 10 years since Rasmus released the first version of PHP.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc