Posts Tagged ‘wordpress’

« Older Entries

Easier APIs for WordPress

Thursday, January 28th, 2010

The secondary goal of the HTTP API was to take something that was difficult for programmers to create or have to recreate with various degrees of success and make it easier. Through all of the WordPress community, we should be able to create something that was more bug free than what others were doing themselves. Trust me, some of the bugs were difficult ones and I don’t think any one person could have solved them all with only part-time commitment.

One of the strengths of WordPress is how easy the APIs are. I can wonder about how much time can be saved if there was a Facebook connect API or a Twitter API that everyone that wanted to use those APIs could do so uniformly. If there is a bug, then it is fixed for everyone that used that API. Well, the argument could be made that since there are a small number of developers that would want to use these APIs that it doesn’t justify adding it to the core.

The point is not how many programmers are using it now, because we don’t know how many will in the future, if such, an API existed. It is possible that one programmer might not know it even exists to know to use it or might not like how the API is used to access the web services. I do know that if the choice was to spend at least four hours studying an API, and then another day to three days developing an API, including testing, I’d go with the already written API.

The biggest hurdle will be writing the “easier” API and then the second will be convincing those with commit access that it is worthy to be part of core. I would like for WordPress to instead include the UI to allow others to develop the UI and extend the features. If WordPress moves to a more foundation, then having easy APIs would seriously beat out a lot of the competition that does not and forces the programmers to develop their own or use a third-party library.

Possibly Related Posts:


Tags:
Posted in Programming | 1 Comment »

Libraries Should Use Liberal Licenses

Monday, January 25th, 2010

One of the biggest concerns I have working on WordPress and developing libraries is that any library I develop is going to fall into the GPLv2 license and I’d rather people use my code anywhere for any purpose. Quite frankly, if someone wanted to take the code and develop a commercial product, then so as long as they don’t say they wrote it, then I’m happy. When writing libraries and code for WordPress, you don’t have that choice or power.

The advantages of having your library as part of WordPress is the support. If there is a bug in the library, then a fix is going to be patched for WordPress and hopefully sent upstream. Plus, the amount of people working on WordPress and fixing problems is going to be more than your project and the number of users is going to be greater as well. This has benefits in that bugs will be found and fixed sooner leading to a faster development cycle that isn’t completely dependent on your work schedule.

That said, a library can be another license just fine and work within WordPress. Any library code I develop for WordPress (controller) is going to be New-BSD and whether it is included or not is up to the developers with commit access and the community. There are others developing a solution that will be more GPLv2, so it is unlikely that within the next few months that I finish my project and port it to WordPress that it will be needed.

The point is, is that applications should be restricted, because they take longer to develop and thus developers using the project have more incentive to follow the rules of the license. A library can probably be recreated within a reasonable amount of time depending on the developers skill and experience.

I think given that fact is why I keep weighing the benefits of using WordPress verses not using WordPress for a current project. Sure, if I focused on just the project elements I could have the project completed relatively soon, but contained within the confines of WordPress and the way it does things, the project wouldn’t stand on its own well enough. The license of WordPress itself is compatible or will be compatible with my project. I’d be using GPLv2 for the application HTML and administration code. It is just simply that I can get away with coding the framework quickly on my own without all of the so called bloat of WordPress.

I can build much of the WordPress core for what I’m needing, the news and content feeds. Really, I think I can probably just strip down what WordPress has and just have a even more limited subset. If I did this, then the code base would be smaller. I could also build a bridge that would take advantage of WordPress, if the application had DB access to the tables. Alas, I could even just go with RSS and ATOM standards to allow for the news to be pulled, but that doesn’t complete the content portions.

Really, that is what drove me to using WordPress in the first place, but I’m thinking that writing a library that is New-BSD would serve my purposes better. I could always use another class library or framework that used a liberal license. That is really the beauty of using such a non-restrictive license, in that you are open to do and enjoy a larger amount of freedoms.

I don’t really mind someone creating a commercial component for the application, because really if there ever grows a community that draws upon the project, then I did something right. Serving a purpose and not limiting people based on some perceived notion of fairness for users totally ignores the real problem. I wouldn’t want someone stealing my code and making money off of my back and off of others, but most programmers don’t sell libraries, they sell solutions and products. A library is not a product and its usage serves only to help create a product, if it helps to create one quicker and better than the programmers using it could have otherwise, then I believe both parties were well served.

Another problem I have with WordPress is that you’re required to work around its flaws to create a product. What does WordPress do well? It does content and administration well, so plugins and applications are built around WordPress that extend these areas. What it doesn’t do well is allow itself to be without neither content nor administration. If you use the administration, then you must use the content portions, there is just no other reason to use WordPress. Alas, you either must use the content portions or you must hack your way around them.

WordPress doesn’t lend itself to applications that aren’t related to content in some way. I do think that WordPress will become better and I believe that most people look beyond the license, because it really is an okay one. For those that wish to do without, there are other projects and frameworks that exist and recreating WordPress wouldn’t take very long.

Well, I say that and really I think people might miss the point with the statement. What I mean to say is that a programmer can develop a theming system pretty easily, it may not have all of the features of WordPress, but it would work fine. WordPress theming and plugin system is simple for most competent programmers to reproduce and even hopefully do better. The bulk of what gives WordPress its size and what would take the longest to reproduce is the Administration and convenience APIs. What I mean really, is that you can do without them. I’m not really saying it would be simple to rewrite WordPress, but to take what it is and recreate it.

Which is what I’m doing, all I need is the content management (pages) and the news (posts). Everything else about WordPress, I can either do without or recreate fairly quickly myself. Still, it seems I would have been better served if bits of the API were liberal licensed. I don’t believe BackPress has a liberal license and I believe that is a shame. Even more so, because most of BackPress could be quickly rewritten with a liberal license and would make it obsolete. Not to say anything about bugs and documentation. However, generally, once you’ve written the API that obsoletes one in BackPress it becomes relatively simple to maintain it and match any improvements made to BackPress.

The point that I’m trying to get across is that applications, if they are done well, are harder to reproduce than libraries. And really when I say fairly quickly, I generally mean someone or a group with a lot of time of their hands with three months to kill.

Possibly Related Posts:


Tags: , ,
Posted in Programming | 1 Comment »

Why Writing Documentation Wasn’t a Waste of Time

Saturday, November 14th, 2009

The hardest part of writing documentation for WordPress was coming to grips with the realization that I could have been spending that time actually doing something. I put aside three browser based games, a library I was working with someone on, and my core web sites to write inline documentation. That I think was a tremendous sacrifice or so I thought at the time. The motivations for which was that I was helping myself by not having to figure who what each function did, what function I should have used, and where each function was located.

Working with WordPress was filled with so many WTFs, I was almost screaming out loud instead of just inside my head. The API in WordPress is so large, learning it is almost like learning PHP. In fact, there were quite a few times, I built functionality that already existed or to need a solution and find it one or two weeks later. Other parts were so convoluted in functionality, it wasn’t worth tracking down each code branch to figure out what was happening and how I could hook in and change it.

The Codex is great for what it is and continues to be, but it is a community project and much like WordPress is an Open Source project, they both suffer from the same problem. Motivation and the surplus or lack of it. Writing documentation for the codex is a massive project, because you have to explain things so that people can understand. Writing inline documentation, you have no such restrictions.

Inline documentation is technical and to be read by programmers of various skill levels to provide the additional information for understanding what the function is used for. Furthermore, each function, object, or documented code is independent of everything else. With Codex pages, often you must tie in multiple functions to explain a given concept well enough for the layman to understand how they may be used together to create something great.

So, my motivation was that since it would take a fraction of time verses writing Codex information, it would be better to have completed inline documentation that changes with the code than to spend forever writing Codex documentation that has to continue to keep up with the changes of the code and will have a harder time keeping up to date with the code changes after the page has been written.

I believe with the introduction of books that WordPress may be served better by those who wish to write documentation for money than the community benefit. Well, each really will serve each other. Authors of books will have a limited space and thus may only devote as much as they can towards certain topics that help the reader get into the flow and basics of working with WordPress. The Codex goes into more technical information for various subjects dealing sometimes with topics outside of WordPress, but dealing with WordPress. For example, hosting, mod_rewrite, and other hosting techniques that can be used to enhance, secure, and improve the WordPress experience.

Actually, I should note that there were quite a few patches that gave me a leg up during the early parts of the project and towards the end people did help. Now that I’ve done other things, there are still people maintaining the documentation. In the beginning, I had the feeling that everyone wanted someone else to write the documentation, because no one wanted to be tasked with such a long and tedious project. When the choice is doing something you enjoy verses something that doesn’t benefit you but other people, then well it is understandable. My prediction was that once someone had put for the effort and completed enough to set a standard of quality, then others would join.

The problem is that when you have a culture that doesn’t have an emphasis on writing inline documentation, then few will do so. It is not fun writing inline documentation and is often a lot of work. Also, it would have felt like pushing back the waves of the ocean, so yeah. People can see the benefits and it is easier to continue once most is already documented.

That isn’t to say that it is perfect, people still need to work on the inline documentation, to improve it, to ensure that the documentation doesn’t become outdated from changes of the function, to make sure that undocumented functions are documented soon after and to make sure that future functions are documented before they go in. WordPress may have started with very poor documentation, but it would have been a lot easier to improve the documentation if the decision was made 4 or 5 years ago rather than 1 or 2 years ago. Going foward, it has to be up to every contributor to ensure that WordPress continues to raise to 100% of every function, class, etc be documented and maintain at least 30% LOC to Documentation LOC ratio.

For the project to go from 4% to 8% ratio 31% is nice, very nice. It also took a while to get there. What I benefited from it? I benefited from the experience and knowledge with the ability to write phpdoc docblock style comments without needing to look up what each tag does, what it will look like, and how it is used. It speeds up my ability to write inline documentation and thus I write more of it in my own projects. I’m finding that it wasn’t a waste of time and that it has and will serve me well in the future.

Possibly Related Posts:


Tags:
Posted in Programming | 3 Comments »

Why I Contributed to WordPress

Thursday, October 29th, 2009

I thought it was interesting when someone made the argument that if plugin authors wanted money, then the developers who contributed the most to the core of what makes WordPress should receive money as well. Well, this might become a reality when and if the WordPress Foundation is ever created. From examples of other Open Source Foundations, usually what happens is that funds are directed to those who contribute in hopes that they will continue to contribute or get new people to contribute full time.

Until the WordPress Foundation is created, if it will ever be and there aren’t any suggestions that it will (that I know of, this is hypothetical), then I don’t think I would even take money even if it was offered. I didn’t jump into the development of WordPress core and fix bugs, because I thought I could make money from it. I seen a problem and decided to fix it, because it would benefit me, that fact that it also benefited other people was a bonus. The most important factor was that it would benefit me. If any of the work I’ve done seemed selfless, then you don’t know me well enough to realize that it was purely selfish reasons.

Not selfish in the way that I desired fame, fortune, or gratitude. Truthfully, I could still care less about that and I think those who seek those things will be sorely disappointed when they find that it doesn’t work that way. I don’t believe it should, but contributors have different motivations. People who work on core are not well known. Well, this is a generalization, I suppose that people know who Dion Helse is and several of the other people.

I suppose the problem is that while I’m not particularly well known, I’m not obscure either. Lorelle has mentioned my name at a few WordCamps (in relation to writing documentation). I have a feeling that many people were wondering about my name, “Who is that?” What I find interesting is that I can go to any given WordCamp and only a few people will know my name. Most know me, not from my work on the core, but for other reasons.

I think that is funny, I set out to create change and I only changed anything by attempting it myself and even that wasn’t my original goal. Whether or not I changed anything else is debatable. Working on a project can be enjoyable, but expecting fame or money just isn’t going to happen, unless you put yourself out there doing other things. By the end of next year, hardly anyone is going to know my name.

I suppose that is the cycle, except for the more veteran members.

Possibly Related Posts:


Tags:
Posted in Projects | Comments Off

WordPress Plugin and Theme Scope

Saturday, June 27th, 2009

If you are unaware, in many cases the files of your plugin and theme will be run in function scope. If you are expecting that your code is being included in the global scope and your code works that way, then you’ll be caught with a surprise when bug reports creep up about the plugin not working correctly. The problem will persist as the WordPress versions continue to “encapsulate” the plugin and theme code.

The best way to get around it is to always use functions and have all of your code loaded that way. This shouldn’t be a major problem with themes, since the WordPress environment is included in with the functions (not always for plugins when activating). Most themes shouldn’t rely on the non-WordPress globals. I fear that more WordPress theme frameworks will and the problem might be found in those so called frameworks as well.

Possibly Related Posts:


Tags:
Posted in Web Applications | Comments Off

How to Not Write a WordPress Plugin

Wednesday, June 17th, 2009

To often there are articles about how to write a WordPress plugin or theme, but not quite enough on how you shouldn’t write a WordPress plugin. Given how often I find a plugin or theme that just wasn’t written to my standards, I’ve decided to shed some light on this.

  1. Using a single object for every bit of functionality.

    This annoys me. This doesn’t follow proper object-oriented programming of reuse and while it is extensible, it still requires modification to the plugin code, which will be lost on automatic upgrade. The problem I have is that, yes it is easier, but not for the person modifying the code. I suppose the argument is that, if you are going to be modifying the code, that you instead just extend it and replace the parts. I will contend that if it was written properly, I would only have to inject my object into the main class or drop a replacement class.

  2. Adding code in the global scope.

    To often I will see code in the main plugin file that has executable code in the global scope. I should make this clear, all executable code must be within functions. The reason? Well, when a plugin is activated or in some instances, the plugin will be included within a function. This will mean that any code in the global scope will now inherit the function scope, so if you were expecting to replace a certain global or set a global in your plugin file, then you were doing it wrong.

    The argument for getting around this is hackish. If your plugin has the following code, then you are doing it wrong.

    <?php
/*
Plugin Header
 */

global $my_global;

    Sure, it works, but it is not clean code and besides, you are only hacking together the 5% chance that the plugin is being included within the function scope. In most cases, the code would already be called in the global scope and therefore it makes the global redundant. There are two methods for correctly solving this problem. One is procedural and the other is object-oriented.

    I won’t get into the code example, but it should be obvious that the initialize function should create the global and set its value.

  3. Not including documentation.

    Well, not really required, because I mean, who is really going to want to mess with your plugin except for you? Unless you have a popular or really useful plugin, then I don’t think many are going to dive in to your code and modify it. That said, it helps, not only you, but any developer who decides to extend or modify your plugin code.

    Don’t be like the Akismet code base, be sure to include inline documentation.

Well, there are many more, but I believe the topic is more geared towards general best practices when it comes to development. Documentation, testing, and deployment. I’ll probably continue this series based on plugins that I find, but at the end of the day, what really only matters is whether the plugin or solution gets the job down. While mileage will vary, it is safe to say that most do.

Possibly Related Posts:


Tags:
Posted in Programming | Comments Off

WordCamp Chicago

Monday, April 6th, 2009

I have plans on going to WordCamp Chicago and WordCamp Dallas (which is relatively closer). I’ll probably be staying at the cheapest hotel in the area and I’ll be driving. I thought about going to WordCamp New Orleans, but I might do that next year. I made a commitment last year that I would go to at least two WordCamps (well, actually I wanted the second to be San Frisco, but I won’t be able to afford a plane ticket, and I’m not going to spend three days driving). So, it is going to take 6 to 8 hours driving to WordCamp Dallas and 8 to 9 hours driving to WordCamp Chicago (depending on where it is).

I have plans on recording sessions in HD at both places. I could have a live cam, if I wasn’t using Vista or the video camcorder had Vista drivers, but alas, it does not. I don’t think they are going to create one for Vista either. Well, actually I do have a web cam, but that is such poor quality. I would only do it if I was close to the speaker. I think the other point is that I’ll need to take my PC and laptop to pull it off. I’ll have the software on my PC, not my laptop and given how much video I’ll be recording, I’ll need to store it on my PC, which will have a lot of RAM and hard disk space.

Between now and the two WordCamps, I need to buy Adobe Elements bundle, 2 1.5TB hard drives, and 8 GB of RAM for my PC. I’ll also need to buy hotel rooms for both places and save money for gas and food. I’m unsure, if I’m going to attempt to even try to get plane tickets. I hate driving all that time, but I’m not going to spend $300 on a plane ticket, when I can drive and spend less than $100 on gas. Actually, I can drive about 300 miles on a single tank of gas. So if it costs $20 to fill up, I can get to WordCamp Dallas and Chicago for ~$40. So yeah, it is going to take 8 hours given to get to both places, but if I have to drive 3 hours to get to the airport for a cheap price and then spend 4 hours on the plane, then I’m wasting too much money. Not to mention, if I’m flying then I either need to rely on some guy driving me around place to place (hey I do have a HD camcorder, so if you want me to record the sessions, I could be picked up).

Right now, I see a flight to Chicago, for $280, which is non-stop and will only take an hour and a half. I like that, because I’ll only have to drive an hour and then another hour and a half. Two and a half hours totally beats 8 hours, but it costs too much. There is a $160 plane ticket for Dallas, but I’ll need to drive 3 hours for a 1 hour trip. So either way, I’m going to cut my time in half for a lot more money. I’m not going to be flying.

So I’m looking at 8 hours. Hotel prices are pretty cheap, so depending on the venue and how close I get, I’ll probably spend a lot less money then I think. So without the plane ticket, the total money I’ll be spending will probably equal one plane ticket. There are a couple of restaurants I will want to go to. In Dallas, I didn’t really get to go to many restaurants and I want to try the Chinese down there to see how it compares.

Possibly Related Posts:


Tags: ,
Posted in General | Comments Off

What I’ve Learned From WordPress

Sunday, March 29th, 2009

The experience with working with WordPress the past year and a half has been educating. While the solutions found in WordPress aren’t exactly perfect, I’m finding that verses others a lot of what WordPress does, is what I wish other web projects would do. I’m also finding that I develop more per the techniques that WordPress uses for themes.

Plugins

On the topic of plugins, if I had not worked with WordPress, then I would never have seen it as filters and actions. My solution would have been to use the Adapter Class Pattern for replacing functionality. The problem is how to handle allowing multiple implementations and the Adapter pattern does not handle those well. Could use the Observer pattern, which is more or less what WordPress uses.

The solution in WordPress is not tied to any one class, uses an unified API, and is extremely easy to work with. That I think is what allows WordPress to be as simple and easy as it is. Sometimes, adding content, replacing content, and extending, doesn’t or shouldn’t involve editing source code, but hooking into a filter or action. It is not required to know how it works, just that if you use this hook that you can manipulate the feature to your requirements.

With the Adapter Pattern, you have to know specifically what it is you are replacing, and how your replacement will work with the code. It works well the use cases where the implementation you are handling isn’t as simple as filtering content or specifying an action. The advantage is that, you can use the same API within the code to do something else. So a multiple step process would be great for the Adapter pattern.

Themes

For themes, what I’ve learned from WordPress is that it is not enough to provide data and handle it, but to also provide the API for handling that data. It is easier and a lot more faster for the developer who doesn’t think or realize that other non-developers may need to make changes to the theme to handle the data directly. The problem stems from those who do not know the PHP syntax and what problems arise when you screw up that syntax. I think that is why Smarty is used for some templating systems. If you screw up Smarty, you are not going to bring down that page, it just won’t display correctly.

I’m not saying that Smarty is better than straight PHP, just that Smarty has its purpose. You can make PHP just as fool-proof as Smarty, if it is done correctly. I suppose, the issue is still one of education. I create iterators with my data, and also methods for handling that data. The work flow is not simple for others and I have to supply documentation for how to use the iterators and methods. I believe that once people know what they can do with the iterators that they find it is easy to work with. Looking at the code, is another matter and you really need to know what you are doing in order to modify it.

Beautiful code is not in the implementation but the use, you are abstracting away difficultly from the user and sometimes the implementation is going to be seriously ugly and there is no way to make it beautiful. The best that can be done is making sure the user doesn’t have any problems in understanding how it can be used.

Developing Solutions

It is always my goal to strive to develop the best solution, no matter what, but given my limitations, I think the best I can give is one that is working. That I think is important regardless of the solution. I think developers get caught up on how well the solution functions verses that it is even working. It is not to say that improper or poorly developed solutions shouldn’t be criticized, because eventually, the solution is going to have to maintained.

The better the solution is developed, the easier the solution will be to maintain, extend, test, and refactor. That has always been my goal. The problem is that when you work with new patterns, data structures, and APIs, the solutions don’t always work out that way.

Roles and Capabilities

The point with WordPress is that, it has shown me solutions that don’t work that well. The Roles and Capabilities API and data structures work within the WordPress application, it is just not something you want to duplicate elsewhere. What is great about the Roles and Capabilities implementation, is how the API works and what data it contains. There are probably three or four core ways to develop Roles and Capabilities in web applications. Well, there are many more; anybody who developed any PHP application will have their own, it is just that they’ll fall in line with the general other solutions.

What I like about the WordPress solution is that you aren’t using levels, which if you’ve ever developed a solution using them, you’ll soon find that it is very limiting. You aren’t using the sort of CRUD permissions that phpBB and Zend Framework uses. I’m not saying that the solution found in phpBB and Zend Framework are bad, it is just that for most simple applications, you are more concern with simply if they have the capability to do something and not whether they can browse, but not delete, or read, but not browse.

That is not to say that certain aspects of the WordPress roles and capabilities doesn’t fall into that model, because certainly parts do. It is that not enough of it does and that you can still implement the CRUD way using the WordPress implementation. The difference is that instead of having one row, you will have, at most, four or five. Not that it makes any difference, because your concern will be for one or at most two of them and not all of them.

Also, it is difficult for me at least to visualize how every capability would even need most of the permissions. If I just need the capability for reading, why am I needing to tell whether they can delete, there is nothing to delete anyway. I believe those work that way, because in administration, you are going to be implementing the majority of the permissions anyway. Administration, yes, normal web applications you don’t, where you still need to be able to tell someone can to do something, but not whether they can delete, read, browse, edit, etc. In this instance, the way WordPress does it works very well.

You can work both ways into any application, it is just that the way WordPress does it, is easier to visualize, easier to implement, and a lot easier to check against. It is the way the roles and capabilities are stored in WordPress that I don’t agree with and well, it is something else in developing a table structure, because there are many ways to implement that as well.

If I had not seen the way WordPress developed their solution for roles and capabilities, I would probably continue to either use levels (where I needed a simple, quick hack). If I needed something more complex the way Zend Framework and phpBB solves it.

Interfaces

I’m used to torturing myself when developing user interfaces. What I’ve learned from WordPress is that it isn’t a good idea to do so for your users. They want simple, easy and less steps. What we are fine with doing as developers of our own work, users only concern is just getting stuff done.

I think I’m taking that more to heart as I use more JavaScript (jQuery, etc) to develop user interfaces. I’ve found that you can go overboard and interfaces should still be developed for those who don’t have JavaScript enabled. It is easier to work with JavaScript to give the interactivity of Flash for web sites, but all the features of HTML with regards to search engine support and mobile browsers.

Well, the study of User Interfaces is a whole another topic on to itself. There are jobs out there just for those who develop user interfaces and research and develop them. For me as a developer, it will continue to be something I research and study, but will never be my primary focus. I’m hoping to meet someone who can do that for me, eventually, or if the projects I work on start making a profit, I can hire someone to do it for me.

Installing

I used to take installing for granted. I’m not saying that I included them in all of my projects, because I don’t. It is just that I was used to modifying configurations manually and setting up the tables and what not manually as well. Most of the projects I’ve used have always had a manual installation process.

I don’t think that is as useful any more, because the best web applications out there, have automatic installation process for which you can configure when you setup and it will do everything to get the web application functioning for you.

For me, after seeing the many installation processes that exist, I don’t think I’ll ever develop an open source project that forced you into running SQL to create the table structures yourself. It isn’t too difficult to implement something that does it for the user. Well, to be honest, the previous projects I’ve developed, the installation has always taken a backseat, because I didn’t need it and given the time I had to work on the project, it just never got to the point where I could devote time to it.

I’m going to change that. It doesn’t have to be difficult, nor does it have to hold your hand completely. Therefore, I’ve done it easily before. It was just a page you went to, that would do a few things to setup the application so that it was ready to run. It didn’t take that long and while it isn’t the best implementation, it works.

Conclusion

I think this is mainly why I’m not going to be developing patches for WordPress any more. I need to spread my wings and take flight and make my own mistakes. Working and fixing the problems within WordPress has been fun and a learning experience. I need to make my own mistakes and hopefully someone will come along and show me a better solution.

That is not to say that I won’t go back to WordPress in the future, because I plan on it. I plan on taking what I’ve learned in my future open source projects and applying them back to WordPress. Hell, given the time it is going to take to finish the PBBG projects I have in store for myself, I think by the time I go back to writing WordPress patches, other problems and solutions will have found their way into WordPress.

So I’ll like to thank the WordPress community for helping me and not kicking my ass when I was too harsh.

Possibly Related Posts:


Tags: ,
Posted in Web Applications | Comments Off

CorePress: The Experiment

Monday, January 19th, 2009

The truth is, I don’t like the direction that BackPress is going. I think it suffers or is going to suffer from the Blob anti-pattern that a lot of object-oriented WordPress plugins follow. Whether that will ultimately be the case, it is sort of already seen with the Taxonomy BackPress implementation.

The point is, I want to set an example of how it should be done, if the person writing the example had about 10 more years writing objects and coding using object-oriented patterns. I’m just winging it people! I’ll fail, it is a given. I do wish to prove what a rough of what it should look like. That said, the developers behind BackPress and bbPress are far more experienced than I am. It is a wonder however why the objects aren’t better designed. Take the Roles and Capabilities class API, it is well done. The purpose of the objects are well defined and abstracted.

I think the point is of differing opinions and practices of what objects should encompass. I believe that objects should serve a single purpose and everything outside of its scope should be in its own class. You can take this too far and create too many objects which while they are well abstracted would probably better serve as functions.

That can be another problem. On one hand, if you create a God object, then all the user has to do is use that one object, but it also can’t be used for anything else. It can only be used for its one purpose and you can’t easily take out the installer portions and use them for other projects. On the other hand, if you create too many objects, you have an unwarranted complexity and without documentation, no one knows how to combine the classes to create a concrete application.

I tend to implement on the latter than the former, whether for better or worse. I’m not yet into UML, so my coding tends to involve a lot of refactoring. Therefore, I’m going to try to release version 1.0 as quickly as possible, that way the API is locked and only bug fixes will be applied. In that way, I can see what problems arose with the design of the classes and understand where I went wrong for the version 2.0 refactor release. When I release version 2.0, I’m not going to worry about backwards compatibility, so that I can get rid of the problem areas that do quite suck.

The principles of the development of CorePress is as follows:

  1. Test-Driven Development.

    The API is not going to be released (as final), unless every component has at least 90% code coverage. In this way, many of the known use cases will be covered and edge cases and unknown use cases can easily be covered on top of the current code coverage. It should provide a great deal of additional stability and that is important for a library that no one is going to use except me.

    Also, test-driven development techniques will be used to help design the library to be as easy as possible. I think it is better to find problems with the design before most of the class code is written.

  2. Documentation and Developer Manual.

    Documentation is important for a library, because if the developer doesn’t know how to use your library, then they most likely won’t bother to use it. All of the code is going to have inline documentation describing the purpose. There will also be a Developer Manual with sections for each of the components, detailing the use cases and examples of how to use the components. I think with both of the two documentation, the API and manual will go a long way to help those that choose to use the library, when it is ready to be used.

  3. Licensing

    Well, part of the problem is that either WordPress does the job too well for me to rewrite it or I’m not skilled enough to write it well enough anyway. Therefore, I am going to be using parts of the WordPress library that will be clearly documented as such and licensed under the GPL. This won’t stop most of the library from being New-BSD licensed. The important API parts will be New-BSD and hopefully, I can write the security layers to protect the API from hackers without digging my paws into the WordPress code. If I need to, those sections will be independent from the CorePress library.

I plan on releasing 0.1 version at the end of February, so whatever components are complete at that point will be released, with the exception that the DB, Plugin, and HTTP components must be completed. If those components aren’t complete at that time, then I’ll have to push the date back. I believe that I’ll have those three components done before the end of this month, so I’m not so much worried about it, but completed also includes documentation and I haven’t started the developers manual yet.

Oh yeah, I’m going to base the Developers Manual off of the docblocks in the code, so I’ll just improve on the current inline documentation and add examples and better explanations in some cases.

Possibly Related Posts:


Tags:
Posted in Projects | Comments Off

PHP5 Straw Man Argument

Monday, January 19th, 2009

Perhaps I’m wrong with this, I don’t want to have my foot in my mouth, so I’m not going to mention very many people by name. Except for Matt Mullenweg, just wanted to plug his new domain for reasons I’m not entirely sure of. Well, or it could have been that I started this off, in an attempt so that you’ll be baited to believe my lies, sort of how Al Franken works with his books.

The argument basically with why WordPress doesn’t transition over to PHP5 has two parts, or two main parts. The first is that users won’t benefit by any way from the transition. The second is that PHP5 offers nothing that can’t already be done in PHP4. These two are true, but I’ll counter them anyway.

The point with programming standards and languages is never about users, only the end result is. End users don’t give a rat’s ass what language the product is as long as it fulfills their needs. Quite selfish of them really, wonder why they matter in the first place. Ah yes, they pay the bills, so I suppose it is a good idea to kiss the ground they walk on then. If users don’t care about what programming language is used, then who does? I wonder.

Could it be programmers? Nah, if that was the case, then the argument wouldn’t have any relevance. It is funny, because the people shouting and arguing about transitioning over to PHP5 are not users, but developers using WordPress.

See the issue with the statement is that the argument actually is relevant, because users and their needs runs the direction of the project. If the users wanted WordPress to wash your feet, while giving you head, then by damn it will be done! It might take forever and cost an exorbitant amount of money for the end product. As I said before, users of WordPress don’t care about the language, if it was written in Python, then people will be looking for hosting that offered Python in order to use WordPress.

To say the least, the reason, which bears the most importance in the discussion is that there is still a large minority of users still using PHP4. With most hosts, they’ll be able to upgrade with either a click of a button or at least a directive in their configuration. No, they won’t benefit at all, but that leads to the second part to emphasis the straw man more.

“There is nothing that PHP5 offers that can’t be done in PHP4.”

This is true. It is completely possible to offer WXR support in WordPress, however the regular expressions does amount for a fair quality of bugs and WTF?s when other people don’t follow the format set by WordPress correctly. If something like SimpleXML and, or DOM was, were used, then there wouldn’t be an issue and the iteration might even be faster. The point still stands that a great deal of XML features would be tricky or require a whole lot of additional work to support both PHP4 XMLDOM and PHP5 DOM extensions.

The other problem is providing automatic Daylight Savings transitions, where you don’t have to set the time manually. This is easily solved with PHP5 DateTime classes and functions, but not everyone has the non-standard PECL extension to allow it in PHP4. Actually, shared hosts don’t have it at all. Well, at least one feature that could be provided, if WordPress required PHP5 and dropped PHP4 support.

Well, besides the XML stuff, the DateTime seems to be the only known issue that can’t be easily solved without moving to PHP5. That is, I’m writing a library, which is for WordPress, that is completely OOP, so we’ll see just how well it holds up with the ease of use of the current WordPress API.

I believe that as developers push the limits with WordPress, more and more reports will come in that basically say, “Well, if WordPress supported PHP5, this would be incredibility easy.” Well, I think that is sort of the issue with the statement. Sure, the daylight savings issue could be solved in PHP4, you could connect to the timeserver for the timezone and get the time based on that server and update the time for the user. That is quite convoluted solution. I think using regex to parse XML is also convoluted. Better solutions exist in PHP5 and as the development of PHP4 has stopped, continuing support for it becomes an issue.

No new code should be written for PHP4

Truth is, no new code should be written for PHP4, because that version has reached the end-of-life and no new versions will be made for it. That said, projects like plugins, themes, and independent projects using WordPress should all be written using PHP5. It has almost been a year since PHP4 has end-of-life, and 6 months since they’ve released any patches.

I think that version 3.0 of WordPress will be PHP5 only. Why? Matt Mullenweg has recanted what he said in his PHP5 post made quite a while ago. PHP5 is faster, more stable, and quite frankly better than PHP4, so it makes sense that he would do so. As project dictator, it is really up to him when the project moves over to PHP5+ only and drops support for PHP4.

Possibly Related Posts:


Tags: ,
Posted in Web Applications | Comments Off

« Older Entries