Older blog entries for zanee (starting at number 213)

Choosing a web design company or design consultant?

Choosing a web design firm/company or consultant seems like a daunting task and the easiest thing to do is choose a name you know or go with a company or consultant that X other person and or company has used. This is the wrong way to go about this choice.

Here's an easy and simple guideline to aide in choice of a web design company/consultant.

1. Disregard large portfolios of work. You want to browse a small and recent selection of work. Not that large ports or older works are of no use but you'll want to see what the company is doing in the present. What they have done in the past is no correlation or affirmation on what they can do for you now. Firms especially, as designers that were once there may not be there any longer. If what you like about the firms work was done by a designer that is no longer there that artistic expression or essence will not be furnished in anything that will be produced for you.

2. You are not a designer, you however know what you like and what you don't like. For the most part you'll want to save the design to the designer. Tell them what you are looking for and leave the rest to them. If you don't like the small bit of work they have done recently. You will not like anything the design firm or design consultant has to offer. Designing is an artistic space and you have to enjoy/admire/like the artistic space the firm or consultant is in. Otherwise it's just not going to work.

3. The designer is not an engineer, however there are elements of function that will need to be discussed between the designer and the persons actually building the functionality or engine for the site. In rare cases you will find a designer who can do both. This is an extreme rarity so in those cases you should count your blessings many-a-fold.

4. Web design for the most part is expressed in ONE fashion; visually. Forget all technical aspects in regards to the design until you have visual aspect that you can be happy with. Beauty is of form-and-function but form is your initial attractor.

5. If what is produced is not to your liking then you have the wrong designer. Design by committee doesn't work. Never has, never will. Anything that has ever been produced by design-by-committee always looks and operates in such frankenstein fashion one may as well have not bothered in the first place. Refer to 2. It's ok to say, "Well, I do not like this and i'm going to try another designer". A professional designer will not be offended and may even recommend someone else in this space that is more to your liking. The commission or setup of a design is a working relationship. Any designer worth his/her weight will tell you that much. Any contract furnished by a professional designer will have such a clause in it.

6. Should you find yourself in constant iteration? There is something clearly wrong with the design, no professional designer will put up with constant iteration on their work once they've felt it to be complete. If you find yourself saying? "Can we just tweak this, or change that, or move that". There is an overall problem with the design and you need to either find a new designer or start over.

7. The best design is the most simple design. If you see a lot of clutter everywhere? There is clearly a problem. There are huge design problems that haven't been solved in the relay of large bits of information in all sorts of different context. If you don't have a designer that knows this? Something is wrong.

8. You get what you pay for. Many persons often think design is superfluous and easy. Unfortunately that is not the case. Design is an extremely draining mental task all for the goal of someone not even noticing and appreciating the work in most cases. The web package deals you see around the internet are for cookie-cutter box designs much like McDonalds has value meals. That maybe ok for something small or a site one doesn't really have much invested in but one cannot subsist on value meals alone. If your website is an important part of your daily routine then maybe instead of the value meal you should invest in a proper dinner.

9. There are a lot of bullshit artist out there. You shouldn't be looking for someone who knows all the whiz-bang words. You should be looking for a true designer, one who views the world creatively through the objects around them and is able to put together something functional in a way the rest of us apes aren't. Even if they don't know whiz-bang technology, that work can be assigned to someone who is ore capable in that realm. This doesn't mean the person doesn't know whiz-bang it just means they don't considering Flash, ASP, .NET worth mentioning. The same way a construction guy doesn't say Hammer, Screwdriver set, pipe wrench know-how! This type of person doesn't follow whiz-bang anything and in general will use all the tools available to them to get what they want.

10. Another tip is to find a designer who actually has a studio or works with other designers in actual creation of products/stuffs/tools/whatever. If all they have in their portfolio is web design then you aren't dealing with a designer. You're just dealing with someone that understands HTML. These are clearly two entirely different beasts.

Syndicated 2010-10-06 15:18:55 from Christopher Warner » Advogato

1 Oct 2010 (updated 1 Oct 2010 at 13:29 UTC) »

Plone 3 Intranets Review

Plone 3 Intranets

Víctor Fernandez de Alba

When Packt asked me to review this book I have to honestly say that I wasn't looking forward to it. Plone as a product has a notorious track record for what I believe to be not the friendliest or most accessible documentation. Regardless of it's technical superiority and usability, it's a glaring deficiency. This is getting better with time but there is still a lot of work to do. Unfortunately my apprehension was filled with curiosity and I agreed to do so at one of the busiest times for me. That and the fact that instead of going on another tirade about documentation it would probably be useful to use my own guidelines in reviewing the book. <h2>Nutshell for the impatient.</h2>

For those of you that cannot wait, have ADD, or TLDR syndrome here's a short summary. Actually, this may come as a shock but I really enjoyed the book. My initial wanton and disregard was primarily for Chapter 8 but clearly it was simply due to context. Packt should really not use that as a sample chapter for this book, it's a complete turn off for several reasons. I will pass that gripe along. That said, there are some tidbits in this book that really make it a good reference manual and a keeper for at least a little while. In regard to technical documentation that means it's something you probably want on your shelf if you're doing anything with Plone and intranets in the forseeable future. Quite frankly the book should be updated in minor fashion with a subsequent release for Plone 4 as not much has changed and it will help to get the book in hands of more new administrators and users of Plone. With some very minor changes this book could be called Plone 4 Intranets. This issue was most likely do to time constraints as Plone 4 has only recently been released. The intended audience for this book is administrators or new users who tend to do their own administration and I think it's successful in reaching that audience. That said on a scale of 1 - 10 I give the book a strong 7. <h2>Chapter 1</h2>

The introduction gives a good general background to Plone and how it came into existence. Discussing the excellent security track record of the CMS and it's general history up until present. It then begins to segue into the more complicated but powerful features of Plone. Workflow, States and Transitions. This chapter also covers and introduces Python and ZODB (Zope Object Database) and why they are useful not only to Plone but to the entire content management space. It's short-and-sweet providing just enough information and background to make it useful to the reader.  There is also a nice overview of the Plone community which introduces the reader to the entire community with a great handshake and welcome that is actually quite refreshing. An introduction on the fine line between extranet and intranets and how the spaces merge in some use case is a great cap for this chapter. <h2>Chapter 2</h2>

Some introduction to the ZMI (Zope Management Interface) and a discussion of blob file types with no background was a bit too early I believe. The issue is that blob file types are native to Plone 4 and not Plone 3. It's again an issue of time constraint and it must of been difficult for Victor to find the right balance between the two versions but I just don't think the mention of the information was relevant here. Also even though ZMI is explained in detail it will be a little hard for non-technical users to fully grasp. The installation of Plone is shown with the Buildout system instead of the unified installer as a first option which I felt was a little hard to swallow as well. For non Plone users this will all seem foreign extremely early on in the book. However the book shines in guides for installing with the unified installer on the major operating systems environments. This really should have been outlined before the buildout instruction but even there the documentation is precise. The explanation of buildout and how it functions is really good and it takes you down into the specific sections for each buildout configuration which is quite handy. If you don't know how to install Plone or have been having trouble you can follow along step-by-step with these instruction.

All in all Chapter 2 feels a little abbreviated and some of the concepts I felt should have been introduced through a relevant example in using them. If you are well versed in Plone it may seem rote here but will make good printed reference material for buildout. Otherwise this chapter maybe slighty confusing to a completely new administrator of Plone. If as a new user you aren't readily thrown off by Buildout introduction you've survived one of the more difficult chapters. Also there is no dire need to use buildout. If you are confused then I recommend reading the sections for the unified installer specified for your operating system and it should help you along digesting some of the concepts. <h2>Chapter 3</h2>

The chapter starts off with creating a Plone site named "intranet". That one example would of been wholly useful as a step through from Chapter 2. That said this chapter gives a great overview of the breakdown of the default Plone theme installed with Plone 3. This has since been replaced in Plone 4 but that is pointed out in the chapter. We also get a well versed overview of the Plone user interface and how one can go about navigating it. As well as a few good examples on adding some of Plones default content types. This includes a walk-through and breakdown of the content structure and default hierarchy of a Plone site. The Dublin Core Metadata specification and good coverage of creating content in Plone is discussed. Including setting up content with some of the default content views. This chapter will certainly help the intended audience in navigation and use of Plone's interface and it succeeds in a comprehensive overview here. <h2>Chapter 4</h2>

In this chapter we deal with the configuration of Plone through it's configlets. They are identified, explained and then broken down into a detailed explanation of usage. Good coverage of ZODB (Zope Object Database) packing via the maintenance configlet and the issues and concerns wrapped around that. There is also a section specifically page 65 which discusses the fact that Plone 4 has its own UI for site creation that simply feels a little out of place. The mention of this should have been in Chapter 3. Otherwise this chapter gives a great overview of the power of the ZMI (Zope Management Interface) and how it can affect site health if administered incorrectly. A valid and perfect apt warning as we delve deeper into the ZMI. For anyone well versed in Plone this is simply a fantastic overview of the ZMI and all of the objects related to Plone. Adding new products is also discussed in the two- way fashion. Meaning the old style products and the new standard de facto recommended procedure of using buildout and eggs (like zip files). The example given for eggs is really a poor one I believe. TinyMCE is native to Plone 4 and even though this book is specifically for Plone 3 one has to suspect that some users will just grab the latest package of Plone which will cause problems. Other than that this is a great chapter that begins to show you the power of Plone and the ZMI. <h2>Chapter 5</h2>

This chapter begins one of the most important series of chapters in regards to Plone. Managing users and groups. The discussion on roles in Plone as well as the entire overview of the security system is excellent coverage of the topic that simply doesn't get much mention at all. Even experienced Plone administrators or developers get confused about the setup from time to time. So for instance, the fact that roles are isolated so an editor who may have the rights to edit content may not have rights to explicitly read that content. For that you'd need to be granted the reader role. This chapter also covers how to create and manage a new user or group. There is also more coverage of administration through the ZMI to create user and groups. The author even clears up some common misconceptions that a new administrator to Plone may have such as confusing Plone PAS with the Zope PAS module. This is a solid meat and potatoes chapter. <h2>Chapter 6</h2>

Next in this important series of chapters is Managing Workflows. This is probably one of the most critical and useful topics covered in this book. So far and up until this point there haven't been many visual diagrams and explanations for the most part. With the exception of stepping through commands we don't get much visual aid. This begins to change here as it begins to become necessary. There is great overview of workflows and what they are comprised of. Including coverage on out of the box workflows related with Plone. The difference between a state and a transition and what you can do with each specific action. There is also light discussion on tales/tal which exposes the lack of documentation on topics like ZPT (Zope Page Templates). The book does it's best to provide a link but no coverage is giving there. Quite frankly one should be able to pickup another manual on ZPT or the likes but a comprehensive manual doesn't really exist here.  We also talk about some third party add-on products for Plone primarily  collective.workflowed, collective.wtf and DcWorkflowGraph which simply is a requirement if you are going to be doing anything with workflows. I really wish one tool was chosen instead a discussion of the three. Having the three divergent paths even though useful in the context of choice may confuse a new user should one of those paths fail. Otherwise this was an excellent chapter and worth the read even if you are an experienced Plone user, administrator or developer. This chapter along with the previous one make this book worth keeping as a reference manual. <h2>Chapter 7</h2>

Security is important and this chapter covers securing the intranet. Concentrating primarily on permissions and workflows the chapter goes into great detail on converging what we have learned up until now in the previous chapters. The differences between Global and Local roles is great. I feel the discussion on Anonymous, Owner and Authenticated functional roles was a bit brief and needed much more detailed explanation. The coverage on actually creating and implementing a policy is pretty good. From outlining requirements, building an example intranet workflow, creating a private section for your intranet and even taking into account third party addon products security and settings you will be well versed towards this chapters end on security. This is also the chapter where we start to see a bit of python code that quite frankly is ok. There is a note, noting that basic product development will take place in Chapter 10. New users to Plone will most likely have to skip to this chapter to ramp up and immediately cover that background if they would like to continue following in earnest but it's not absolutely necessary. There is also a discussion on collective.sharingroles at the end which nicely caps the chapter. I'm not sure if it's absolutely required, but it's a decent addition to the overall chapter. <h2>Chapter 8</h2>

Using a content type effectively. This chapter in the context of reading the book is completely useful. Otherwise in the context of simply a sample chapter it's useless. Quite frankly, there is nothing in this chapter that isn't already on Plone.org in some fashion. This doesn't exactly entice one to buy the book, as I read this as a sample chapter I said to myself, I have already read this stuff many a time over. Sans this one gripe in this chapter you'll learn about creating collections and querying the ZODB (Zope Object Database). We also learn about the useful features of other out-of-the-box Plone content types. Other than that there is not much to say about this chapter. I wouldn't have necessarily called it useful outside of the context of the book and even in context it's more of a standard straight forward chapter. <h2>Chapter 9</h2>

This is a nice progression from the previous chapter as it discusses external content-types and products that can be used with Plone. Most of these products are primarily for intranet purposes obviously and a good over view is given of each product. You have calendar, events, blog, survey, poll, document management and form generation products. In specific the form generation product covered is PloneFormGen and I'm pleased that this was the only thing covered on the topic of form generation. There are actually other different ways to create a form but the author picks one and sticks with it. An experienced user or administrator of Plone would be able to branch off where necessary. Also the discussion on the document management products is really quite useful for intranet settings. This chapter is great in introducing these add-on products that most intranets will need to use and gives a good overview of each different type of product. <h2>Chapter 10</h2>

This chapters goal is to introduce the readers to the basics of Plone product development and I think it succeeds in that regard. It steps through the basics of creating and building a completely useful product it's not as comprehensive as my own documentation on the topic but it's very comprehensive and readable. GenericSetup the tool used to manage some of the major tool objects in Plone is broken down in detail and explained including a matrix of all the relevant xml and it's subsequent description. There is even an example of cloning a content type with GenericSetup through the ZMI (Zope Management Interface).  The only issue with this chapter is any mention of Dexterity. Dexterity is on track to be a replacement/sister for Archetypes. Unfortunately there are some sacrifices that will be made and  incompatibility with the previous Archetype system is unavoidable. Quite frankly Archetypes will be around for sometime to come and there is nothing useful to be had by even mentioning it in any context at this point in the book. <h2>Chapter 11</h2>

Content rules are triggered based on Zope event handlers and this coverage is pretty decent you'll learn how to create rules and have them triggered based on specific event. You'll also learn how to create syndicated feeds from folderish content type objects. However the most important piece in this chapter will have to go to versioning. Versioning is an absolute requirement for any content management system and Plone has a simple and straight-forward way it handles changes to content. This chapter will give a great overview of how to use the versioning system as well as managing version policy. The WebDAV and External Editor coverage is also useful. <h2>Chapter 12</h2>

Chapter 12 starts with the pronouncement "Theming -- what a huge subject in Plone!" This is quite right as Plone and theming opens all avenue of possibility I was surprised to see this chapter in this book. After reading it and with the prior knowledge that there are numerous other manuals, reference material and books on the topic of Plone theming this chapter is in my opinion superfluous. All that stated the chapter does give a decent overview of theming Plone. Changing logos, managing viewlets describing the page render process and useful tools like Gloworm it makes itself a chapter of bonus material. Viewed in that context this again makes the book a solid and useful reference manual. <h2>Chapter 13</h2>

This is simply a great chapter that discusses proper deployment of Plone for three different types of deployments. Victor goes into useful detail on site deployment describing it as a continuous process there are many different options and implementations but breaking the process down into 3 different deployment sizes is reachable. We have small 1-50, medium 50-100 and large 100+ every essential process for a working deployment is covered from backing up, restoring and packing the database to rotating log files, scheduling, virtual hosting, load balancing between ZEO clients for redundancy, caching and even externally authenticating against LDAP (Lightweight Directory Access Protocol). Each process has enough coverage to get any of your deployments off of the ground. The only thing that I think is missing from this chapter is a way to assess and manage performance which I would have easily given up chapter 12 for. All in all however the final chapter in this book is yet another solid and useful chapter in what has turned out to be a great and useful manual. <h2>Recommendation</h2>

All things considered this book in so far as a technical manual is great coverage of the topic of Plone and Intranets. The author does an excellent job in conveying the material and even if you aren't doing anything with intranets there are several solid chapters on Plone deployment, theming and others that make the book a solid purchase for anyone planning to use Plone for almost any application. I give the author my congrats and highly recommend it as a solid buy.

Syndicated 2010-10-01 02:18:36 from Christopher Warner » Advogato

17 Sep 2010 (updated 17 Sep 2010 at 20:09 UTC) »

Forget Agile, try Software Engineering.

Here are some tips on my new methodology in no order for software engineers and management. It's not XP/Scrum or any take on Agile because NONE of this is Agile in definition, manner or anything else. I like to call it, "Software Engineering (or SW for short)". I'm gonna make this short and I'm not going to qualify anything because I don't feel like I should have to.

  1. Should you need someone to tell you to chop up your project into smaller units that are more easily digested? You're a bad manager/team lead/leader/whatever you are calling yourself. Needless to say a two or three year old is smarter than you and that MBA money went to waste.
  2. If something is a smaller unit, that doesn't make the problem you are trying to solve through programming or anything else any easier.
  3. If you need someone to tell you that you need to sit down and discuss what you plan to do before you do it? You're a bad manager/team lead/leader/whatever you are calling yourself.
  4. If there are more bad than good things to say about something. It is rotten, throw it out.
  5. No external force can run your company better than you and your employees.
  6. Team building involves no methodology, it's a constant reassessing and making tough decisions. You want to make your weak programmers strong and reward your stronger programmers appropriately. If you need someone to tell you this. You're a bad manager/team lead/leader/whatever you are calling yourself.
  7. If you are a programmer that can't say "I don't know, i've never done it before" or "This will take too long for X reasons" and/or "I don't know anything about X". Grow some backbone, you seriously aren't all knowing either so stop acting like a dick.
  8. If you are a manager practicing Agile in any context. You're a bad manager/team lead/leader/whatever you are calling yourself.
  9. There's nothing Agile about agile; Work is work, someone has to do it no matter how you cut it up. Agile doesn't make your resources work faster, more smoothly or any of that.  Building a comprehensive team does that; not some methodology.
  10. Why can't you all be like Google and have the best programmers/admins working for you? You don't reward or pay a decent salary, and then on top of that you use crappy ass tools. Google is only successful because good programmers decide to work for Google; not because they have some secret sauce. That's how it works for ANYTHING. When the best people want to work for you well then you're gonna corner any market they are in. If all of Google's programmers left tomorrow they'll be a closed shop soon as those programmers go to Doogle.com or whatever.
  11. How can I get the best programmers working for me? Choose the best tools and only the best tools. They will come looking for you; guaranteed. In your next job posting put "We like to use these tools, because they are the fucking best most awesome kickass tools available and we are building great shit." Also, i'd recommend not having HR write up the copy and less the profanities. Keep it simple, short and to the point. See what type of reaction you get.
  12. Software engineering is mentally draining. It's not like filing papers. It isn't rote, so you can't treat your employees like it's some factory line.
  13. The best feedback you get is from your programmer and if he/she gives you a comprehensive reason on why X is horse shit and it makes sense. Heed that warning.
  14. Here's a typical stakeholder request. "I want to go to Mars". Here's a typical agile response "Lets break that story down into tasks and see how best we can do this if possible or break the overall problem into multiple sprints". Here's a typical Christopher Warner SW response "Well, I don't know if i'm in the right room at present but this is not fucking NASA, there would have to be a lot of work to get there maybe you should think about getting to Florida first".
  15. Here's a typical Agile question "If you're in a space and lost your tether and you had X tools which one would be best to use in aide of saving your life". Here's a typical agile response "The gun would be best". Here's a typical Christopher Warner response "You're fucked". It doesn't matter what tools you have at that point. The idea is to NEVER lose your tether so you never have to make that decision.
  16. How do I know I have a good programmer/admin? He or she is usually busy getting shit done, and pretty much needs little to no management. They tell you what's going on, how things are progressing. What issues problems, concerns they may have etc. Pretty much everything is quiet on the front when they are around.
  17. How do I get a team of good programmers? Good programmers will want to work with good programmers. Primarily because when one gets lost it pays to have a decent wing man or someone who can say "Welllllllsssssstttt this isn't working because you're a fucking idiot and wrote this module wrong, you're a dumbass. We'll work it out over lunch.. you know what?? lets finish this in X's office she's working on some similar shit; we'll order up. Bang this out and then hit the gym, after the beer you buy me. It always taste different when you buy it".
  18. How do I reward my team? Contrary to popular belief, money is on the top of the list but sans that proper recognition. Beers and pizzas and all that shit, save it for highschool. At the very least offer expensive liquor, we are all adults here.
  19. How can I be a better manager/team lead/leader/whatever you are calling yourself? Make sure the road is paved and fill in potholes. When something from the top comes down that is horse shit? Say "This is horse shit". Don't go back to your team with a "This is horse shit but we have no choice."  Say "This is horse shit, I said it's horse shit and I explained the detrimental waste of fucking time. They still want to do it. Of course, you guys are free to do something more awesome and when asked I'll show them more awesome with a, my apologies, I guess this more awesome thing I have right here will have to suffice" or "Sorry we just can't fucking do this stakeholders.. It's just not possible for X reasons, the top one being that I know my job better than you and this request is simply  in management lingo, UNpossible". Wrap that in termination free language; unless you happen to be in a mood in which case have another job already lined up and be sure some of your team can come. Don't want to abandon them.
  20. "I don't know anything about computers I just want a measurement of when I can expect things!" When it's done, or accept variable estimates. Unless for some reason you believe the art of writing a program to be a measurable unit of work. In which case, let me explain. Writing a program is much like being an artist. You start with a blank canvas with a couple of constructs and then you have to take whatever came out of the human MIND and create a reality out of it. Think it's easy? Think of anything you have never done before until now.. Now go build it, but before you do. Tell me when it's gonna be done. I'll wait.
  21. Anything successful takes a long time of proper foundation building, team building and regression. If you don't have that or experience it. You will not be successful. It's that simple there is no methodology or luck involved besides hard work and building a good team. FOR ANYTHING.

Ok that's enough. I hope you apply "Software Engineering" as a method to your next project; even if it isn't software.

Share/Bookmark

Syndicated 2010-09-14 18:24:03 from Christopher Warner » Advogato

Relational Databases are killing content management.

Why LAMP is wrong for content management

LAMP. Linux/Apache/Mysql/PHP,Perl,Python is THE opensource software solution stack for programmers/administrators doing almost anything, specifically rapid application development on the web. There are numerous frameworks that pull all the pieces together in hopes that large and parcel anyone can build robust and usable web applications and websites. This includes content management. For the most part this works well, even through the hurdles of getting all of the specific components to work together nicely. Unfortunately the masses have taken the context of building anything to mean that LAMP is the ONLY solution to building applications on the web.  So the standard de facto has been to look at a problem and automatically assume LAMP as the underlying technology for the space. Blog? LAMP. Twitter like site? LAMP. Website for my company? LAMP.  Simple web page with a small contact page? LAMP.  To be fair, this works well for many context spaces. Especially because the LAMP system is highly modular one can literally pull one piece of the overall solution set and replace it with something completely different. However as any engineer and architect will tell you. When building a bridge, it helps to know what is going to travel over it, under it, through it and unfortunately, into it. If not you end up with something like this.

The collapse of the Ironworkers Memorial while under construction on June 17 1958

The collapse of the Ironworkers Memorial while under construction on June 17 1958. Collapsed during construction due to miscalculation of weight bearing capacity of a temporary arm.

This is generally what content management tends to resemble when it meets the architecture of LAMP. The software solution set is a complete failure for content management applied as a standard de facto solution primarily because of the M in LAMP. In this case I mean Mysql but the problem in actuality is any RDBMS or Relational Database Management System. It's not the only problem but it's one of the most critical components to getting the idea of content management right.

Lets start by taking apart the LAMP acronym.

Linux; As far as the operating system goes. Linux is a tried and true system which has been under development for nearly two decades. It has consistently pushed the envelope in regards to utilizing the underlying hardware to provide a robust and capable operating system that can scale from the server to the desktop.

Apache; As far as web serving goes. Apache is again, tried and true and has been under development for nearly just as long with many lessons learned. It is the standard de-facto server for serving static/dynamic content with an extensible and modular system which makes it capable of providing support for many different applications and setups.

Mysql; The relational database management system that had the honor from many as being the first RDBMS they used and the cut throat bare bones data solution. In early Mysql releases there was no idea of ACID Atomicity, Consistency, Isolation, Durability in the project. This overhead was seen as generally a problem that could be solved higher in the application space but for the most part everyone using Mysql during that time had no need for such compliancy. This made Mysql extremely fast and of course, with the exception of Postgres (which did concentrate on these things) it was opensource and freely available. Things have changed much since those days, Mysql has generally become ACID aware and is surprisingly owned by Oracle.

Perl/PHP/Python; For the most part Perl as a language was dominant in the 90's. Since then it's fallen behind in regards to the web application space. There are numerous reasons for this but one of the major reasons is that many new programmers have written Perl code that is difficult to read and maintain. The language wasn't originally intended for large object-oriented projects (Ruby which has syntax largely like Perl was written primarily with object orientation at its core and the Ruby language has a vibrant community and a popular web app framework called Ruby on Rails or ROR) and maintenance has generally become a nightmare. This isn't a blackmark against the language past it allowing poor practices that have seemingly been embedded with the programmer. As those new and junior programmers become more literate their Perl code improves but those old projects and web applications they've written or help write don't fare as well. There tends to be a group-think backlash against the language because of that. "It was written in Perl? Ugh.. nightmare".

PHP tends to have the same exact problem, low cost of entry, except the community around PHP is wholly vibrant and releases often. PHP as a language itself has had many of the same problems as Perl in regards to building a large software project. Most of which have been remedied with time, namespace support, halfway usable object orientation support etc. It still lacks many commercial features that you can't readily use without purchasing them or their frameworks.

Python on the other hand, has a much higher cost in regards to learning curve than the previous two. However it's still a very easy language to learn and enforces many good practices out-of-the-box that the other two languages don't. Proper formatting, a useful object oriented system, the idea of namespaces, unit tests and code structure. These are all important concepts in architecting software (building your bridge) and it's a viable language.

Ruby isn't a P but needs mention as it's also a dominant language used. It's highly object oriented and as stated above has syntax largely like Perl. It's essentially referred to some as "Perl done right"  and it's primary author has stated that "I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python. That's why I decided to design my own language".

So what is the problem with Relational Database systems and content management?

Relational Database systems are from an era where object-oriented programming didn't readily exist large and parcel. The concept of an object quite frankly was  foreign. Most programming had been functional and procedural, no one had any idea how useful it would become. The general crowd-think was more concerned with "records"; it had worked well since the 1940's and many companies had spent large sums of money setting up internal systems. A nice line printer spilling out data onto dead tree's with a list of users, phone numbers, etc. It was easy, pulling out all of this information. However as time passed and with the advent of the internet the concept of object-oritentation became more important. Java came to dominance because of this. We needed to do more than just relate information but also update it real time, expose it to other systems in-house and to our partner systems. Records in a flat table were simply not enough, we wanted to have a representation of a user and all of the attributes important to us updated dynamically as they were updated by our staff, customers or both.

Computer languages started to reflect this fact. Most languages started receiving object orientation methodologies. C got it's OO super set in C++ and then there was Objective-C which got it's clothing from Smalltalk and obviously Java. Which sparked a new commercial trend and is probably the most dominant object oriented program in use today.

Cube vs Cylinder

Square vs Circle, Cube vs Cylinder, Oil vs Water.

Unfortunately, as the way we wrote programs changed, the way we stored the data our programs created or needed did not. Programmers began writing Object Relationship Mappers ORM's to map the objects they created in their programs with the way they stored their data. So one would design a user object with a name, address and phone number in their program and then have to create a table for this in the relational database and then have to map between the two. Obviously for time sensitive applications the overhead of conversion became an issue. More importantly though a whole system to manage the consistency between the two became an issue. If one got out of sync with the other it would cause no small amount of trouble for critical applications.

Enter Object Oriented databases or OODB's. A programmer could create the object in his program and store it into an object database. Early versions were considered slow and inefficient however OODB's tended to hold more data than relational database systems, were generally faster than relational databases as there is less to lookup and no overhead or extra systems to manage between a relational system and an object system. As well as being more secure it seemed like an easy win however there was no uptake. Most commercial organizations were and still are used to the idea of a "record" and Oracle as a company is simply a good salesman; they came up with Oracle Object Relational support. OR in more simple terms a superset to SQL to make Oracles relational database behave more object like. Also the sheer force of SQL and the relational database eco-system made it hard to see through the clouds. In-fact, most people didn't and don't even bother looking. There was no real advantageous reason to go with an object oriented system if you had an object relationship mapper. Summarily, no one took up OODB's except for organizations in the know, primarily scientific and engineering houses who had large amounts of data they needed to warehouse and work on. Every one else stuck with RDBMS, until it started hurting them. They would eventually retool by either finding and consulting with Oracle or one of the commercial Object Oriented Database providers. It's a testament to Oracle's success that they are the ONLY database game in town. Really, what other commercial database company can you refer to off the top of your head? I'll wait... Right, so that leads to the present day where there is more talk of Nosql databases (object databases, graph databases, high perform key/value stores etc things like HadOOP, CouchDB, MongoDB, Redis, Neo4j, Allegrograph) but not much has changed in the last two decades. This time around things seem much different and the database playing field is bound to go through transformation with web semantics and html5 database standards. We can only wait and see.

In the interim the previous decades were simply unfortunate for database stores and summarily the content management space as it is highly object oriented. Your customers want to manage content. Videos, Users, Large lists, Blogs, News, Images etc. All of which are objects that need to be stored somewhere, and for the most part that is occurring in a relational database. Which means one has to overcome the problems above and 9 times out of 10 it requires a lot of time and engineering that simply isn't done properly. Hence choosing the standard de facto in LAMP, the bridge eventually collapses. A collapse maybe downtime, or loss of records, or constant maintenance, security threats all of which can be lessened by building the correct bridge for the problem space. In content management that is an object database; or some combination of nosql/relational and object data depending on application.

How do I change the M in LAMP to an O for object database or something similar?

Well, if you plan on managing content there is ZODB or the Zope Object Database for Python which is part of the overall package for the Plone Content Management system. There are also DyBase, db4o, Twig etc. Past that your options are currently limited without an object relationship mapper but it pays to understand the problem space so you can architect your content management solution appropriately even should you need to keep your data in a RDBMS. Whether it be for something as simple as management of blog data or a large list of data it pays to know that you have a bridge that can withstand all of the nets elements. Hopefully, next time you are talking with your consultant, client, design company or web team and you hear LAMP you have a better idea of what it entails and how to apply your business needs and process using LAMP if you need to. LAMP isn't always the answer and it certainly isn't always the answer for content management solutions.

Share/Bookmark

Syndicated 2010-08-30 19:47:00 from Christopher Warner » Advogato

What computer should I purchase?

Recently I had a conversation with my brother about his purchasing of a new computer or a better computer and here are some recommendations that I feel will be useful to anyone looking to do the same.

  1. You don't need the newest whiz bang feature. 9 times out of 10 most people are using their computers for email/facebook/music and web browsing.
  2. More expensive doesn't mean faster. There are a whole host of reasons this is the case but a big price tag doesn't make for a faster machine.
  3. If you know very little about computers. My recommendation is to purchase a Mac. Simply because you don't have the where with all or knowledge to manage a Windows machine. It's simply too complex fighting off virus after virus. Even for very experienced Windows administrators.
  4. If you know a thing or two. My recommendation is to still purchase a Mac. You obviously have work to do and spending time fighting all of the intricacies of Windows doesn't sound fun or productive. [1]
  5. If you want to build your own I would spend time researching copiously your components. Computer hardware moves faster than anything else in any industry. Period. Right this instant the card you are looking at is the fastest. Just now, in the time it took for me to type Just now, it became maybe Top 5.. maybe. By next week you'll be lucky if it's still there. A month from now, new Whiz Bang GTX with 50 more whiz bangs will be out.
  6. Do not purchase cheap. If it's $300 bucks it probably won't last two years. The components are cheap and will break down and you will find yourself spending another $300 or more and would have saved nothing. In-fact with the time you spend in repair and with a down computer plus all the etc. Might as well have bought a quality machine. If you are like me and a computer is vital to your lively-hood, you should make tactical measure to only buy quality gear. It need not be expensive, but quality. IE: If I purchase memory it will only be ECC memory. If you know what that means, it's a clearly obvious decision.
  7. Buy refurbished quality gear from the manufacturer if you can swing it. You'll get burned-in tested gear in near brand new condition for a fraction of the price that has been certified by the manufacturer. It's an easy sell.
  8. Keep your computer for as long as possible. At some point your needs may change and you may need more whiz-bang feature. It's at this point when you need to upgrade. I see too many people upgrading for absolutely no reason. They get no benefit AT ALL. Nothing is inherently faster for your needs just because it is new. For instance, I try to keep my main desktop running for at least 5 years before I even consider an upgrade. The machine that handles most of my network traffic has been in service for close to 12  years. This idea that computers are throw away products is harmful. They contain all sorts of toxic compounds and most are serviceable, usable and capable for a decade if not more. Consider recycling or donating your computer. Throwing it out should never be an option.

All that said if you still think you need 30 inches, 12 cores, 72 GB of ram, 4 TB of SSD hard drives and a goddamn pony. Feel free, it'll be obsolete by tomorrow and you're 30k investment will be worth 10% of that by next year. In two years, it'll be in a dell catalog for $300 dollars.

Needless to say I have a variance of kit that is useful to me but somehow people seem to believe that the more they spend the better. This is wholly incorrect.

[1]: Right, so some idiots will jump to conclusions of fanboyism tirades as to my recommendation for Apple kit (even though I hold no such allegiance.  I use Linux, Freebsd, Opensolaris, Openbsd and have DEC!, Sun! (Dec, Sun are no longer but they built some of the most long lasting machines known to man), etc etc kit all over the place for my needs). Unfortunately, when it comes to quality built hardware there are few consumer manufacturers that do it well. Even Apple has some shoddy gear. However, out of all the consumer manufacturers I would choose Apple first over any other. They provide decent quality components, in a nice overall package that holds up over time for your run of the mill user. It also comes with solid software packages all for a reasonable price. The same can't be said for Dell, HP, Compaq, Etc. Windows as a general purpose operating system has historically been  and is still pretty much a complete failure. OSX concentrates on the user and the tasks they need to complete; which is why we have computers and why you need one.

Share/Bookmark

Syndicated 2010-08-17 16:00:13 from Christopher Warner » Advogato

Selinux is not for desktop usage

Ok, let me state emphatically. Selinux[1] is probably the most secure environment and system that you can get for free. It's emphasis is on a RBAC model which is different to lets say OpenBSD security through code approach. Anyway, I don't have time to get into a lengthy post about all of this right now because my brain is tracking on something else except to say that I don't believe Selinux is useful on consumer grade desktop systems.

In tight-security corporate roll out environments or secure military facilities or some such; it  only makes sense on the desktop there. However i'm speaking about RUN-OF-THE-MILL machines. So you're desktop at home? It's retarded to have Selinux there because a run-of-the-mill machine is constantly changing needs and is general purpose. Writing new policy for every new thing you plan to do is a little silly. Especially because that policy will probably be insecure ANYWAY and it takes time to vet.

So Fedora with Selinux? Dumb. Ubuntu user distro with Selinux? Dumb. Etc user distro linux? Dumb. You get the idea. If you want a secure desktop, turn on a firewall and flip on encryption of your most sacred files. Apple has Filevault which is implemented extremely poorly even though I use it, obviously if you are using Unix then you are aware of your options etc.

[1]: http://www.nsa.gov/research/selinux/

Share/Bookmark

Syndicated 2010-08-05 13:57:07 from Christopher Warner » Advogato

Extending a default Plone Content Type commentary

So you want to extend a default Plone Archetype Content Type. You start saying to yourself, i'm actually recreating an event content-type why not just utilize Plones existing type. You know about archetypes.schemaextender [1]and are thinking to yourself. This is going to be a cake walk. I'll just adapt whatever content-type, lets say in my case ATEvent. You then waltz along saying to yourself let me reorder the schemata order. However, you can not do this. That sucks. Then you start thinking to yourself, maybe I shouldn't use archetypes.schemaextender. I mean, it's getting a little silly with all of these workarounds I'm doing for the most basic content-type stuff. It's obvious I want to do more than just add an option or two onto the main content type. Yeah that's the ticket i'll be adding new methods, browser views, candy, ponies, etc. So you decide that you will subclass one of the main plone Archetype content types and be happy. Unfortunately you then realize, you're basically copying the whole content type out of Plone and recreating it.

This is when a light bulb goes off even though it's ever so dim; you just need to make your own content-type. If you're lucky enough, you would of already did all the work like myself and will just need to continue on. The bright idea of you reusing Plone AT Content types for more than just a boolean option or some string material is just a dumb idea. Seriously, it's just a dumb idea.

You may still think it is a bright idea. I really mean it. It is not. Go ahead.. Try it. I'll wait........

See? Dumb idea. If you were smart and heeded this advice without trying it then you've just saved yourself a couple of hours worth of work. So when is it a good idea to use archetypes.schemaextender? Well if you need some minor annotation to an overall content type it makes sense. Usually information that you won't have to display readily or override views for. You know, like a boolean option that will trigger a subscriber or some such. Or some other tiny bit of stringfield information where it's just a tiny change and not much of the overall schema is being modified.  When you start talking about more than that, just go with your initial gut feeling and do your own thing. If you really want the functionality from the default Plone content type you can always rip it out and throw it into your own content-type.

Now today doesn't feel like such a waste. Cheers.

  1. http://pypi.python.org/pypi/archetypes.schemaextender
Share/Bookmark

Syndicated 2010-07-27 20:08:39 from Christopher Warner » Advogato

Race and discrimination; Political Correctness

Rarely do I go into discussion on what I believe to be off-topic issue but this needs to be said because I have eyeballs. Race and discrimination as an ongoing issue doesn't interest me as I feel many strides have been made. Many more will be made and the topic in and of itself seems to be on level with religion. Every side is right and if you are on the opposing side, you are wrong. It doesn't seem any one side can take a critical look at themselves or offer valuable critique of the other and that means it is just a general morass of mess. It just keeps popping up in my life, most likely because I am a black male living in the United States of America.

Unfortunately the discord continues here in the USA and currently the flames are fueled by rhetoric from what many have deemed to be the "Right" wing of American politics. Sometime ago, if asked, I would of said it's simply safe to ignore it as intelligent people tend to ignore such things or at the very least collectively work towards marginalizing the behavior. Over the last decade, this theory has been proven wrong to me numerous times over. So after revisiting this and thinking about response it became clear that organizations such as the NAACP and others are wholly inadequate at dealing with the issue. Personally I suspect they are able to hire appropriate PR people but maybe that idea is wrong. I've not seen a solid formal response to many things from them. So, should you be planning to respond to some racial rhetoric it's important to note several things.

  1. There is no need to get emotional. It is indeed what the other party is looking for and as we all know an emotional response is not effective. The response should not be argumentative because it is not an argument.
  2. Persuasion happens by not persuading. Persuade by your actions and not by conversation or argument. It is also wholly ineffective in this case.
  3. It is ok to be angry if you feel injured or hurt. You should channel that energy into something positive.
  4. Stand-ins, sit-ins and civil disobedience works for some things. For others it doesn't. The notion that standing somewhere will change something is idiocy. What will change something is collective organization and changing it by all means available until it is so. Stand-ins worked when people didn't want you to stand where you were. I think as far as civil rights go we are past that.
  5. It pays to be smarter. Know your position and every detail, know their position and every detail. Refute anything that is inaccurate; improve any weakness.
  6. Timing is everything, so bide it.
  7. It is safe to ignore some things. Not every piece of racial rhetoric deserves a remark. Realistically, very little of it needs remark, you can generally pool most commentary into a pool and provide one response to that.
  8. Some will claim that violence is a proper form of response. For instance shooting an unarmed human being 50+ times and then being fully acquitted is unacceptable in any conceivable context. It evokes a feeling of rage. However the proper response isn't a stand-in, march, or protest. See 4. You'll be surprised to see how effective anger can be for fuel; it is very focusing. Obviously, i'm not saying you should not protect your families or loved ones. In the United States of America that is every free mans right. I'm saying calculated behind the scenes efforts are wholly more effective; combined with 6 they are even more precise and deadly.
  9. Nothing is ever one groups problem. Ever. So for instance, the racially motivated discrimination or killing of one group should be every groups problem. We all have our preconceived discriminations based on race. We should work toward eliminating those beliefs when they are clearly invalid.
  10. It's safe to realize that first we are human beings and secondly that as a group we have our collective fair share of idiots, scumbags and people who should really not be apart of our species. Unfortunately, they come in all color and sizes. Weed them out; See 8.
  11. Not everything is racially motivated. It's safe to say that sometimes I just don't like a person for whatever reason. That is fine, we are all human beings and that is a fair position to have. It's also fair to note ones experience or reaction to something. Sometimes I wonder why senior black people are so racist? Then I realize that some of them were children of slavery, racism, discrimination, they lived through riots, attacks on their families and such. I have to take this experience into context and be fortunate enough to realize that I haven't had to deal with race and discrimination in this way in my lifetime.

Onto Political Correctness or PC. If you have to be "PC" about something it usually means there is an underlying issue that needs to be addressed. So it's better to address the issue than to be PC about it. Should someone feel offended by something you've said then humbly and gracefully apologize if that wasn't your intention. If you have to validate an apology then it's not really an apology, try to take their experience into context and avoid doing so again.

We are humans and as much as we think we all fit a mold of behavior, feelings and passion we are highly unique and complex in the universe. Also, feel free to stop saying I have "black, asian, white, indian or whatever friends". That doesn't validate or excuse you being an idiot or discriminating against someone at the time. Anyway.. I guess I'm gonna just call this end of lunch for me.. cheers.

Share/Bookmark

Syndicated 2010-07-16 16:09:52 from Christopher Warner » Advogato

DublinCore Metadata

So, most of us have heard of DublinCore before, which is why I'm not going to into a long spiel introducing it. What I want to talk about is the lack of use it gets. Realistically, no one is using DublinCore in an exposed useful manner . Meaning, when my developer cap is on I can easily pull DublinCore associated data from an object. When my administrative or user cap is on it becomes near impossible. Exposing this metadata set is important! As a user I want to know what the rights are, or who created a specific object/resource/page whatever. As a developer I'd like to pull this data and mash it up with my own development.

Yes, I know what you just said. The meaning for the terms in the element set are so obtuse that it can be interpreted almost in any fashion. Thinking about the possibilities becomes almost mind numbing. .oO "Simply the standard is broken by not being specific enough Mr. Christopher, blah blah, lets hit this beach". "Whatever dude, who cares.. no one. that's who. No one gives a shit, pardon me while I drink this beer..."  It need not be so however. Instead of recreating ones own metadata set which is doing the same exact thing. We should be looking towards exposing this data and then ADVERTISING that it's available. It's also easy to simply generate the required data for most of the 15 resources with ease.

How does this help? Well, at the very least people who respect each others Copyrights/Rights and would like to give attribution will know exactly who or what institution to give it to. As well as helping to nail down where data originates etc. It's not perfect by any means and the holy grail solution most likely exist in a W3C standard that gets accepted by the major browsers.

In the meantime maybe it's high time the DCMI community came up with some badges that simply state "This site or resource is DubliCore aware" or "These resources have DublinCore metadata attached" or just a graphic that highlights that we can indeed review or pull the metadata. There is a nice plugin for Firefox called Dublin Core Viewer that does this. Also exposing the data as naturally as possible ie: "Creator" == name of user or some such is also generally good behavior. "Goddd, you're still yapping about this?? Ronnie, pass me another beer.. i'm gonna leave if you keep talking this clickety-click bullshit".

ok.. I'm done... for now.

Share/Bookmark

Syndicated 2010-07-09 14:41:36 from Christopher Warner » Advogato

204 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!