Jacob Santos » Projects

Calibre Improvements

Jacob Santos — Sat, 22 Oct 2011 03:28:12 +0000

There are two aspects of Calibre that I would focus on, if I didn’t have already too many projects on my plate. However, working on Calibre might be a nice break and get me motivated on working on other Python projects, like Trac or Projile.

User Interface

Given what I’ve been reading, I’m thinking of various ways I can rape the GUI layout. What I mean to say, is that while I’m not an expert yet, I think this might be a good start. I can already see where I’m confused by the library software, so I can imagine where other people might be having difficulties. Truthfully, I’m thinking something similar to Picasa 3 and a mix of Kindle.

Separating The Components
Calibre appears to be doing 4 things in the space of one main application.
- Market Place – You can search for books from a list of existing online stores or search online stores for an existing book in your library.
- News Retrieval – Similar to Google Reader, except for syncing with your phone or converting to e-book format and syncing with a device.
- E-Book Sync Service – Allows for viewing the collection on a capable device.
- Library – The main purpose of the software and the majority of the application.
I would want to make the separation more clear and remove the icons at the top. I would also default to the library, but hide the other three sections / components listed above where others can get to them when needed.
Improving the Library
The main actions of the library is adding books, converting books, editing books and removing books. The view is displayed by various predefined, what I’ll call, directories. The other problem is that while a lot of the functionality is geared towards searching and minimizing the amount of books on display, it doesn’t work like a computer or at least is missing normal directory hierarchy. At the very least, a normal directory structure needs to be added to manage what people might already had organized their e-book library.
Removing Books Overload
The other part is why does the button “Remove Books” even exist? The delete button or the right click and “delete” option has the convention of being used for this action on every piece of software. In fact, such a right click menu already exists and simply has the same options. I suppose it makes sense, they are trying to make it as simple as possible, but by doing so are complicating the system. Delete should simply work as people expect and you should get out of the way. Much of the functionality could had been wrapped into an overall search and book selection that allows for a simple and single “delete” button press or right click and choosing “delete” on the menu. No submenu, just “delete”. The right click option is there just for formalities, the expectation is that it should never really be used.
Adding Books Overload
Same problem with “Add Books”. You can simply drag a file or selection of files and drop them into the library and it will add the books. What is “Add Empty Book” and why is it needed? I suppose it was something someone wanted at one point, but when am I going to use it? Adding esoteric features to the application doesn’t help with the ease of use. Why didn’t the person simply create a txt file, name the file and then simply add it? No matter.

The real problem is that I have no idea if the directories I add will continuously be synced with the application. Meaning, if I add an e-book that I bought from a web site and download it to one of the directories I added to Calibre, will the book show up? Without checking the source and from other hints from the application, I’m going to guess not. It begs the question, “Why not?” I want this to work like Picasa 3, where I’m not adding books, I’m adding directories which are synced with the application every so often, so that when I add a picture for Picasa 3, it shows up and is synced online. I want Calibre to work like that.

The way I would improve the “Add Books” functionality is let you choose which directories you want Calibre to sync. Like Picasa 3, allow you to deselect subdirectories and sync down subdirectories automatically. The assumption would be that filenames or titles that match are the same book removing that feature completely, but allow allowing you to correct the libraries assumption.
Cataloging Existing Books (Hard Copy)
I believe the reason for allowing to add empty books and by ISBN is so that you can list and catalog existing books and display it to people. I suppose to allow them to “check out” the book from you and keep track. However, I doubt this feature is implemented, yet.

I would improve this by simply allowing you to create a new entry and attempting to download a book picture, if possible. I would check for free ISBN and title book look ups. Since Ebay and other applications do it, it shouldn’t be impossible.
Unified Search
Like Picasa 3, I would put the search on the bottom and automatically select based on criteria. Allowing for managing, hopefully, more easier. Well, technically, the search bar will be at the top and the filtering will be on the bottom.
Book Display
I rather like the idea of displaying thumbnails and as the default. I think it is wise to allow for displaying a list, I guess sort of like iTunes. Well, I suppose this would be one preference feature left up to the user. Well, actually, a couple of iTunes features are part of the library. I’m unsure what is better verses Picasa 3 over iTunes. Regardless, I would want to do some testing verses the two and sort of find what works better.
Separate Application for Content Server
Or at least a less visible icon.

I would rather move the content server code outside of Python into a C#.NET application or potentially a D application. I would rather use the .NET framework since it would allow for utilizing the Windows APIs better. I would then write a Linux Daemon in another language, probably D and attempt to do the same for the Mac OS X with either D (preferred) or Objective C. Even if all the Windows Service and *nix daemons do is execute Python to run the code for all of the platforms.

I would also move the “Connect” to a device sync functionality or make the content server a “device” as well.
Modifying Books
There will be a mass edit feature that will be hidden most of the time. I do think that perhaps it will be difficult to use. I’ll try an icon for mass editing that opens a pane for changing certain details. Editing a book’s metadata or information will be similar to Picasa 3 where it will be a new view. The directional keys will allow moving between books.

Actually, I’m starting to think I’m overthinking this. In some ways, it is just as simple as it needs to be. I’m just not satisfied until my tongue is so far up its asshole that it is coming snakes.

Maybe a part 2 later. Maybe.

Possibly Related Posts:

DragonU Bug Tracker Dev – Milestone 1

Jacob Santos — Sun, 06 Feb 2011 07:18:30 +0000

Framework

I decided to build my own framework using Zend Framework as a base. The basis of which is going to have a mismatch of directories. I might look at Habari, Fuel framework, and Kohana framework to see how they structure their directories and files. At this moment, I’m going a mix of WordPress and what I remember from CodeIgniter. Not the best choice to be sure. However, I plan on improving the nonsense after I go over certain details and get the base working how I like.

I switched from Fuel, because Zend Framework has more of what I need to get started faster. The only downside is that I need to setup the controllers and functionality. I might instead, create a branch, that uses CodeIgniter 2 for the MVC for rapid prototyping to be sure that the application is how I want it while I build the official framework for which the application is going to be based. I’ll create this as a branch, if I am going to develop this way. I’ll have to see how quickly I can get the base up and running.

If I get this working, I’ll most likely use it for my other projects, but I might attempt to implement the features into FUEL instead.

Core Application

The core application, I’ve decided is going to be based on Zend Framework and I’m going to make the following changes:

Kohana Style Front Controller. The front controller is going to allow for modules and plugins, which will also have controllers, so most likely, I’m going to set it up to where it first searches the official Router and if it is not found to look at the directory structure for the controller. I like the way CodeIgniter and its clones allow you to easily add controllers without actually setting up the routing, except for the more advanced purposes. I’m going to implement a hybrid system between Zend Framework predefined routing and CodeIgniter style routing.
WordPress Style Script and Style Loaders. I hate having to change the headers and what not and using styles and scripts that aren’t even used on the page. The code will not be from WordPress, since I’m going for New-BSD license, but I’ve already built something similar, and the algorithm is simple, so I won’t have to worry about this feature taking too long. I am going to attempt to add script collisions to prevent duplicate javascript files from being added.
WordPress Style Filters and Actions. I’ve already started code for this and I’m think I’m going to go an easier route for implementing the feature. It will be the 3rd rewrite and 5th overall. I’m looking at probably 4 or 5 hours given how long the other attempts took.
Themes. I do like the way WordPress does themes, so I’m going to attempt to implement this. I’m going to include an API for extending existing themes, setting dependencies, and using the default theme if missing files. The differences from WordPress is that Modules will also define default templates that themes may override. It will be done in such a way to prevent conflicts; the theme module template files will be in a separate directory, ‘modules’ and use the name of the module. In this way, a theme does not need to know about all modules, but may provide for those it knows about and popular themes.
It also allows for placing themes and their additions in one place. Users do not need to put module theme files in the module directory, just the directory of the theme they are using. Given the parent-child nature, if they want to support multiple themes, they can put the modified theme file in the default theme (which is a parent of every theme by default) or the parent or child theme.
Modules. See below section on this.
The goal of the modules is to provide additional features for the Bug Tracker that can be enabled and disabled. Modules may have plugin support, theme support, but most importantly will have separate controllers and models and are basically separate and mini applications for the bug tracker.
Plugins I want the difference between plugins and modules to be that plugins are mostly filters and actions for existing hooks, with maybe an options page. For this, I’m going to include an API for setting the options page, if one is needed. I really want to emphasize the purpose of plugins over modules, so that the confusion of when you would implement one verses the other. I have a feeling that eventually one or the other will win out if I don’t force the issue. Modules will offer Plugins as well, and this may help with the issue of when you would do a Module verses Plugin.
Probably include something similar to WordPress widgets, but I always hated how it was implemented in WordPress, so I’m going to go for something different.
Hybrid Settings Configuration. Setting up and configuring the application should never require editing files, unless the initial database configuration file could not be made. The problem is that this often requires using the database to store the settings. I really don’t like doing that. The base application will attempt to create PHP configuration files for core and module configuration, but will use a database table, if that fails.
Enabling Plugins and Modules will also have two ways to do so. You could enable modules and plugins by including a file named, “.enabled” in the module or plugin directory, but enabled modules and plugins will always be checked in the database. I might also include a third way, which is a separate config file, which loads modules and plugins. I may also attempt to create this similar to configuration.

Extensible Administration and Separate Front-End

One of the concepts I’ve thought on was having a default administration for the application that modules and plugins could extend and themes could customize. I figure actually that customization will be very limited. Only the header, navigation placement and footer will be editable, as well as the CSS and Javascript.

The reason for this is that modules and plugins have their own controllers and I don’t want to force mixing or moving directories. I want modules to be contained applications that all you need to do is drop it into the modules directory and enable it. To this end, the administration of modules has to be combined with the base application administration controllers. It should also give modules complete controller functionality within their scope.

I was actually thinking about including a member profile as a separate system similar to the administration. However, this I don’t think will be necessary as modules and plugins will be able do this anyway. The separation was given the fact that navigation and theming will be different from the front-end and back-end and therefore will need a system to ensure cohesion.

Installer

WordPress has spoiled me, I believe that any application that does make it extremely simple to install, isn’t worth using. To this end, there will be an basic installer that checks against certain requirements and runs queries for installing the database tables.

In the future, I want to allow downloading plugins, themes and modules during the installer process, as well as configure them. This milestone, I’m going to simply work on simple database specific configurations, so that the application can be installed. The rest of the configurations will be done in the administration.

Modules

I’ve already discussed some of my plans on this feature, but really, the purpose of modules is to separate several features of the application into components that the administration can enable to extend what the base application can do. I figure if all you want is simply a ticket tracker, that simply install the application and run with it. If you want a support ticket feature, then you’ll enable the module that implements that feature or any feature you want.

Several planned modules, but not in this milestone:

Support Ticket.
Help and support tickets that aren’t bugs, but would be helpful for future requests and reference. Might be used internally for customers. Will be extremely simple in structure and UI and include public option for allowing anyone to create a support ticket.
Company Projects.
The base application will assume that only one company is using the application and therefore all projects belong to it. Again, this will be a boilerplate module for extending and allowing for this feature. This will really force the base application to allow setting the default controller, overriding defaults, something that is already planned, but in a way to allow for cascading default controllers.

The feature will most likely test the cascading controller in a certain of filter system for setting the priority of controllers. So you could have segments matching against multiple modules. This may require allowing the administrator to set up the priority in case there are conflicts.

So for /{Company}/{Project}/

The company module will add its priority as 1 and the Project priority, which is in the base application will be priority 10. So in theory, you could have another module come along and add region, which would make it, “/{Region}/{Company}/{Project}/” and since the Region will also be priority of 1 will notify the administrator of this conflict and force modifying the priority, so Region is always first and Company is always second.
Repository Activity
There is a difficulty with implementing this feature in PHP. That is, that the implementation will require command line applications and also access to the CLI git, svn, hg, etc on the system for the repositories. Given this requirement, as well as the esoteric feature set in Trac, Redmine, etc. I mean it seriously isn’t strictly necessary for bug tracking and managing projects. It is “nice to have” feature and I plan on using it for statistics of developers.

One element that I’ll implement when I see how it is done in other bug trackers and project management applications is how to get the application to work with Tortoise SVN and Tortoise GIT ticket features. I’m going to attempt to add this as part of core, but the ability to close tickets in the repository commit log will have to be part of this module or implemented as a plugin.

Note About Configuration

The configuration will be file and database based. An attempt will be made to create PHP file configuration, but given any permission issues, the database with caching will be used instead. The purpose is to make the application as easy to modify as possible without having to modify any PHP files. The application is require as little work as possible to setup and configure as possible, but also attempt to be as efficient as possible.

Planned Features In Later Milestones

The first milestone is about getting the base framework working to start adding application functionality. Other planned functionality includes automatic upgrading of the application, modules, plugins and themes.

This will quite possibility use the same system as WordPress, but implemented for this web application framework. The library that WordPress uses is freely available and I believe uses a license compatible with this web application. I will need to implement it separately as WordPress had to include work arounds and WordPress specific code to get the installer and upgrader working. The worse case is to use a separate library or libraries for implementing a similar feature. Well, actually, what is cool about these libraries, is that it might allow for using file based configuration even if access is not granted for creating those files, since the main library is creating files using FTP or SSH tunnel.

Possibly Related Posts:

Dragon MVC

Jacob Santos — Sat, 31 Oct 2009 16:38:49 +0000

I think the motivation factor is to lessen the scope of the project, so that I can get it done and write the documentation and unit tests for the project. If the scope is limited to just the controllers, database API, and view abstraction, then I can probably get something out in about 3 weeks time instead of trying to do many things at once.

I’m going to aim at keeping the components as separated as possible with some connections between the different parts. The view component is going to be the easiest and quickest to complete since it is just going to use PHP templates. I might finish the documentation for the Views first and complete the unit tests as well, so that the project gets off on a good start.

One component that I’m also going to to include is the plugin API. This will tie in to certain parts of the controllers, views, and DB API. I believe most of the real documentation will go into the database API and how to use that. The controller will also need comprehensive documentation, but just not as much as the database API.

I’m going to give myself a month and a half to complete the project with basically an hour a day on the weekdays and 2 to 4 hours on the weekend. I’m going to focus first on the unit tests and try to get as much of the API designed in unit tests as possible. Everything will have phpdoc inline documentation and have all main documentable elements explained. This will carry on to the DocBook documentation, which will try to explain in human terms how to use the library with examples.

Motivation

By giving myself sprints, I should put out a plan and be working on the project a little bit every day. By giving myself a little to complete and knowing exactly when I’m done, I can actually see the light at the end of the tunnel. By giving myself a deadline of a month and a half, I set forth a goal which I plan on completing.

The plan is to have the project functional before the month and a half, but most likely the majority of the planned features for the DB API will not be finished. The DB component will be the biggest part of the MVC and more time will have to be spent completing it. The foundation of the DB API should be fairly quick to complete and will allow for testing.

Previous Attempt

The previous attempt, I believe, failed because I was attempting to code it to replace WordPress without realizing that the API just isn’t going to be able to do that. After I realized that, I had already written the foundation and realized to get it to where it needed to be, I’ll have to rewrite it. I can still take some of the best parts of that API and apply it to the new API.

Instead, by starting over anyway, this attempt will have the design where I want it from the beginning. I think I’m still going to take some of the best parts of the WordPress DB feature set, including HyperDB code base. I’ve been experimenting with different implementations of what is currently in the code, so it is simple to replace the functionality and still allow it to be extensible.

Database API

The Database API is going to be Active Record and take what I’ve learn from CodeIgniter, ORM, Datamapper, CRUD, BREAD, and various other implementations of DB APIs I’ve done in the past. I’m going to try to correct the mistakes of other implementations and code the DB API to the best of my ability. This will not mean I won’t make mistakes on my own. This will be mostly a learning experience and I’m going to try new things in an attempt to simplify the code and how the code is extended.

My hope is to code the project in such a way to allow for experimenting, but also allow for “correcting” shitty code architecture that will creep in with such experimenting. Not all trials will work out the way they should and the API needs to be flexible enough to accommodate that. The other parts of the code base will not be developed in this fashion and the code will not use “experimental” code.

Possibly Related Posts:

Why I Contributed to WordPress

Jacob Santos — Fri, 30 Oct 2009 00:15:54 +0000

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:

DragonU DB Component

Jacob Santos — Sun, 19 Jul 2009 23:00:42 +0000

The concept is fairly simple and helps me develop the component a great deal quicker than originally planned. I had originally planned to have a master DB object that handled all of the major features through a fluent interface. The point now, is that I want to do that, yes, but I want to simplify the code even more.

The problem before was that the scope was too great for me to develop and because it was massive, I had problem testing and seeing where the end was. I have difficulty programming like that. The way I like to problem is by building something that I can understand in my head. If I can’t understand how it all works, then I become depressed, because it is a great deal harder to see where you are out, if where you are going is off in the distance and over the horizon.

The solution now is to create the DB component in smaller chunks. In this way, I can improve the chucks over time and add new features by adding new chucks. There will of course, be problems with this solution, in that it will require refactoring in the future that may break backwards compatibility. I think of course, that to do so, will mean to increment the version. So everyone that uses version 1.x.x will always have compatibility with those versions. When new features are added, nothing will be removed that will break older versions.

Well, right now, version 1 hasn’t been released, so I feel as if I can do whatever I want. Just that I hope to get version 1 out the door sometime in a month or two, but most likely it will probably be sometime early next year.

DragonU DB Connection

The DB Connection object will have several parts and may rely on a config later on. The point is that when the config is added, it won’t require any work to be done to this object it will just rest on top of the DB components, so instead of building the DB connection objects manually as you will have to do when it is finished, you will have a configuration file that you can create the connections and manage them through that.

The purpose of this object is to store the PDO or PDO wrapper for MySQLi and MySQL extensions. The PDO Wrapper object will be developed later, however, the point is to allow PDO, since the API is standard and allows for many DBMS access through it. The PDO wrapper object will be an extra “feature” to allow for other extensions to work with the DB functionality.

After the PDO object or PDO wrapper Object is stored and connected, it will store that connection for the reminder of execution. So you can only have one connection per DB Connection object. If you need more than you need to create multiple DB Connection objects. However, the main library code will only use one DB Connection object for processing.

The code for this will be extremely simple. The connection can be created by either passing a PDO or PDO Wrapper object (it has its own method), passing a DSN string which will be used to create either a PDO (if the extension exists for the DB type) or PDO Wrapper object, or Resource or DB object for the ones that are supported. When the DB connection has been completed, the only other process is to pass the PDO object to the code base that will use it.

DragonU DB Connection Cluster

This works like the DragonU DB Connection object, but instead of passing the PDO object, it will instead pass itself which will in turn iterate certain calls to all DB connections. It will cycle through SELECT queries for each DB connection object in a dumb load balancing fashion.

The purpose of this container feature, is to use multiple connections for selecting and to keep all of the connections synced by passing queries to each of the connections. It makes more sense to use the DBMS cluster feature for most DBMS, but for some reason the feature in MySQL just plain sucks. Until they get it fixed, it will make a bit more sense to use this sort of emulation for the clustering, unless you have a lot of DB servers.

I could probably extend the feature set in the future, but I don’t want to get too far into what the DBMS does better. It is just a simple solution to what some DBMS makes more difficult and asinine than it needs to be. This is all it should be.

DragonU DB Main Component

This is the object that will manage take the DB Connection or DB Connection Cluster object and what other developers will work off of. It will be more of a factory than do any work and will be set up to allow for fluent interface usage. By keeping the main class stupid, it should be simple to add new features to it by what amounts to just “opening the door” to the feature.

DragonU DB Scheme Component

I’m still not exactly sure how I’m going to implement this. I think the simplest way is to create a loader which handles the inclusion of the scheme and passes the functionality, however, I’m thinking of another way to do it. Perhaps the simplest way, is to have the CRUD scheme to where it builds based on the SQL for the DBMS and methods. There can also be an abstract class which handles the non-SQL specific code and the Scheme will just need to implement the code to handle the create, retrieve, update, and delete methods. The problem with this, is that it will require modification whenever new methods are added and not all DBMS has the same SQL.

I believe, that by assigning Schemes to CRUD, BREAD, etc that it will simplify the DB SQL for majority of people and work on all of the DBMS that there is a Scheme class. The developers who want to take advantage of the specific SQL features of the DBMS will still be able to use the Scheme component to allow for that as well.

The point is to focus on the API for developers to use and not on the Database specifics. That should be up to the developer of the library to design and setup for the user of said library. So be a bit more clear, the user of the API should never interact with this layer at all and only the layer either directly above the DB or however many layers separates the user of the library from the DB.

Another key feature will be the way to extend the Scheme dynamically. The point of this is to keep from creating a new class to add functionality, but add functionality through external callable that will be managed externally through a plugin specific to the Scheme functionality.

DragonU DB CRUD Component

The most basics of DB access is the CRUD pattern. I’m going to include it for the simple purpose of easing the usage of the DB component. If the developer wants to develop their code using CRUD, then this will allow them to do so. I’m most interested in seeing how many developers use what pattern. The problem of which is that I’d need to have many people actually use the DB component to get statistics.

The CRUD component will include more than just create(), retrieve(), update(), and delete(). The experiment is to see how people use the fluent interface, so there will be extra methods.

The table() method to specify which table to use.
A where() method to chain the where for updating and deletion.
A select() method for chaining or selecting what to retrieve.
A limit() method to limit retrieval, updating, and deleting.

There will be other methods, which the scheme class will have to support, but shouldn’t extend to the full SQL language. The bits that are needed are to restrict what is retrieved, what is deleted, and what is updated. Extending it further than that is a waste of time to develop for CRUD.

DragonU DB BREAD Component

BREAD is works exactly like CRUD, except you have different and more methods to work off of. The methods are browse(), retrieve(), edit(), add(), and delete(). There difference from CRUD is that the retrieve is both for one or many, whereas the browse() in BREAD is for many and the retrieve in BREAD is for one and only one. The BREAD edit() works exactly like update() in CRUD. The BREAD add() works exactly like create() in CRUD. The delete() methods are the same for both CRUD and BREAD.

The advantage of BREAD over CRUD is in the retrieval. I suppose is arguable whether two methods is better than one. It will be up to the developer to decide whether to use CRUD or BREAD. As it is mainly up to their preference for either one.

Other Patterns

Other patterns will be added as well over time. That is the nice part of the component. I’m not really tied into implementing it in one way or refactoring to allow for more patterns to be added. It is just faster to focus on a few things to get the initial functionality working and usable in projects, instead of having to wait until the majority of it is finished before using the library.

Other Functionality

The functionality covered in this post is just a small part of what most DB component packages offer, so yes, as the DragonU library is developed, more features will be added. It is just better to work off a base that allows it to be done easily and doesn’t require that it all be done at the same time.

Possibly Related Posts:

Working On My WordPress Plugins

Jacob Santos — Tue, 16 Jun 2009 21:47:34 +0000

I’ve been working on several of my old WordPress plugins for the past couple of days. I’m also developing a new plugin. Well, I have plans to develop two or three more, but I’m going to focus on just the one and the old ones for now.

Alternative Mailer
I developed this plugin to work with Swift Mailer and replace the old (at the time) PHPMailer class. However, it sort of just feel to the wayside and I haven’t worked on it for a long, long time. I’m going to go back and add in TLS and SSL support as well as attempt to automatically pull out the attachments and put them in Swift Mailer. This will probably be a couple of days before I complete it.
Auto Scheduler
This will auto queue posts after a certain number that is set by the administrator and, or editor roles. After I do this, I might work on a stack, where the first post is moved up the schedule and the recent post is moved to the front. I think the FIFO is what most people will want. I’m planning on adding it to my web site and I’m thinking of adding another feature to where it doesn’t block certain categories or tags.

This plugin should only take about a day (4 hours) to complete. There are only going to be about three or four options. First option will be to enable the plugin (by setting the number per hour, per day, or per week. The next will be the amount of time to offset the posts schedule. So basically, if you have a number per hour, the offset will be for the next three posts within the next hour. So if you set the offset for 10 minutes, then the next 3 posts will be on the hour, 10 minutes after the hour, 20 minutes after the hour and if another comes in, then it will be the next hour on the hour.

So on and so on. If the limit is 3 per week, and there are 12 written in that week, then posts 4-6 on week 2, posts 7-9 on week 3, 10-12 on week 4. If the offset is 2 days, then one will be on Sunday, the next on Tuesday, and the final one on Thursday. I’m going to also base the weekly on the start of the week. So if the start of the week is Monday, then it will be Monday, Wednesday, Friday.

Possibly Related Posts:

Hurray! I’m Back!

Jacob Santos — Wed, 20 May 2009 00:20:46 +0000

My traffic has basically decreased to about 0, but I’m planning on writing some more for Planet PHP, so that might pull in some traffic. Also, www.santosj.name is redirecting to jacobsantos.com (no www).

My Goals

Design my own theme based off of the WP Framework theme.
Well, I have been wanting to design my own theme for pictures and what not for a while now, the default theme is well, not all that great since everyone is used to it. I want more space for pictures. I want to have a lower area for widgets that will be on every page. I want to design a few plugins so that I can add description and keywords to every page.

Also, I want to display excerpts instead of the full content. I’ll be using the excerpts functionality more instead, but it grows tiresome to have to scroll as much as people do.
Bring Absidongames.com and Dragonu.net Back Up
These sites hardly get any traffic at all, but I’m going to be working on Dragonu.net soon and I’ll be using AbsidonGames.com as I develop the game engine and PBBG. The goal is not so much to work on these sites, but to get them to where they no longer suck to look at, so that means rewriting some of the content and creating templates for the sites.
Backups
One problem I’ve always had, was that I never did any backups of any server I was on. Now, luckily I never had a problem where I lost everything. I had all of the files on my system anyway, except for the database scheme, which I regret, because while I have all of my old sites, I’d have to rebuild the scheme from the code and I’m not looking forward to that.

Therefore, sometime this week, I’m going to be backing up certain files (repositories mostly and configuration files) and databases. I’m debating whether I’ll want to backup the configuration files, I think I am, since why not, it is just one extra line anyway. As well as the cron jobs. I could rewrite them, but I tend to forget things over time and it is handy to have old configuration files around to look at what I did and how it worked.
WordPress PHP Extension
I’m on Linux now, so I have easier access to strace to see where I screwed up or where the screw ups are. The goal is to get back into development sometime after the development on Battle Machines stabilizes. It takes a while to get the game engine foundation built, before the project(s) really take off, so it is slightly difficult to work on projects, because of the appearance of nothing being done.

Which, awesomely, the PHP extension is already started and the foundation is already built, I just need to tweak and develop based on what is already there. I still want to benchmark the benefits of the extension verses PHP userland WordPress library.

I think what is holding me back is that I want to develop for the next generation of code. It’d be interesting to build a new API and then just have backwards compatibility. The problem with this, is that such an API is better written in userland first to develop the design defects out.
Battle Machines
I guess you could already say I have started development on it. Kind of. The problem is that I’m using the Yii Framework. Which I’m not familiar with, so it is slower development, and also I’m more of a visual kind of person, so I like to see what is happening while I do it and well, I need to do a bit more work before that happens.

I’m not exactly happy with the directory structure, but I’m going to wait until I have a working application with Yii Framework before I jump into the code and see about working on ways to work around the directory structure. I hope to develop Battle Machines as an experiment with it and then take what I learn from it and apply it to the game engine development. Well, actually, I’m probably going to continue development using the Battle Machines code base, until which time I find a better way to develop the game engine code base using Yii Framework.
Subversion
I still need to write the post-commit scripts and test them. I also need to setup the cron jobs to upgrade WordPress, as well as the plugins.

Possibly Related Posts:

Working on Quantum Game Library and moving CorePress to QGL

Jacob Santos — Fri, 20 Feb 2009 01:54:00 +0000

I’m really, really anxious to get the browser game sites up and running again. It has been too long and I’m starting to worry that the other developers that have been building it will come and break my legs. I haven’t been a really good host for the past 3 months and I need to change that. Well, I’m going to start with Battle Machines and work my way down the line.

I’m not going to concern myself with building the game engine at this moment and just focus on the getting the games up and running. I will try to base the game code off of each other. So when I start the next project after Battle Machines, I’m going to use as much code as possible from Battle Machines to start the next project. I’m going to continue this and hopefully, by the time I’m done, I’ll have a semi-working game engine. Finally, after the games are back up, I’m going to go back and work off of that code to build a foundation for which to rewrite the finished games and add in features I’ve hadn’t had time to develop.

The focus will also be open source and the Quantum Game Library. I envision that I’ll be rewriting a lot of the code and refactoring. The code I’ll be rewriting, I’m going to place in the QGL for later. It will be one of the ways I’m going to be enforcing reuse between the projects. Getting the game source code out there under AGPLv3 should be a way to enforce changes being sent back to the main project and getting the code out there in other people’s hands. I just want the source to be as professional as possible before I do that.

I’m currently doing some cleaning up of the code. The manual is going to be using another engine, so either PhD or some other easy one. I think PhD works great and is very easy to install on both Windows and Linux. So I’m focusing on that and then I’ll have to revamp the test case system. I’m going to switch over to using PHPUnit and working phpUnderControl software support in there. This should make the process very easy and will hopefully be automated through CruiseControl. Should be interesting.

I’m going to try to get it to where the tests are written in a way that tell me how many components are finished and at what level. Right now the components are that are ready to be moved from CorePress to QGL don’t have enough test cases written for them. I need to drill that down, but I’m more than likely going to focus on the DB component and get that working and then focus on the old code and updating the test cases for them.

Ohloh is going to suck at the moment, because it will have a very large dip of code, but I think that is good at the moment, it will improve the statistics. I think I should have a lot of the old code converted over the weekend.

The components that are completed need to have the amount of test cases and quality of test cases improved. I’m also going to focus on that, but it is easy to lose track of the finish line when you have inline documentation, manual documentation, test cases, and refactoring and component writing. The goal is to focus on the core and DB and current old code to get them ready, so if the library had to be used tomorrow, it would be ready.

I removed the AI code, because really, the code there wasn’t fully functional. I’m going to revisit it, but the graphing really needs to be addressed better to enable the path finding algorithms to be better. I’ll most definitely revisit the AI parts of the library to seriously improve the level of it. It is a lot of work really, so it will have to be after everything else is done.

After the old code is refactored, unit tests rewritten, and manual and inline documentation improved and updated, then I’m going to focus on some other components I had planned for CorePress. The focus is to keep QGL license as New-BSD as much as possible. Therefore, the focus has shifted from providing an alternative companion from WordPress, to redeveloping the concepts that are in WordPress and applying them to the library in a way that doesn’t suck. I like the way WordPress does some code, but other parts of the WordPress library are somewhat awful.

That said, only the components that are needed to fulfill the current projects are going to be worked on. This means the Plugin component, the template, news, and commenting. Categories, tags, etc won’t be addressed until later. I’m not attempting to recreate a blogging platform, just need some posts and commenting. Also a templating system that is actually quite cool.

That said, not everything will be done over the weekend or even next weekend. It is going to take several weeks to finish everything and get everything where it needs to be. I want to start off with a project done right and not have to go back and complete such details. I want to be able to tell people, “Look at QGL, that is how the game and the game engine should be done.” I hope that by providing a good, clean example, others that I develop with will follow suit. Either that, or I won’t have to field so many questions when other developers start working with QGL.

Also, I’m not much of a writer when the topic is really boring like when writing technical manuals. It is akin to someone scratching their nails on a blackboard over and over again.

Possibly Related Posts:

CorePress: The Experiment

Jacob Santos — Tue, 20 Jan 2009 05:59:52 +0000

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:

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.
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.
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:

CorePress Repository on Google Code

Jacob Santos — Wed, 14 Jan 2009 08:16:24 +0000

The New-BSD WordPress Library I’m writing is now on Google Code, and I have a name for it, called CorePress. The name is tentative, because it matches too closely with the other -Presses, I want a new name for it, but that will probably come later. Right now the code name for it is CorePress. If I get enough completed to where I can release 0.5 version, then I’ll think about changing the name again.

I’ve been working pretty much about four hours a day on the library, unit tests, and documentation. I think the good news is that if I do the inline documentation correctly, then I can output the phpdoc docblocks in DocBook format and then edit the XML from there. The goal is to provide a detailed guide on how to use the library. I suppose I can also use the unit tests as examples as well, depending on how involved the examples are. I’ll also need to write a working plugin and theme for the developer guide on how to use the library.

I don’t suppose I’ll be finished for another month or two. The DB portions are coming along nicely. However, they are hardly complete. That said, I don’t suppose I’ll have everything working in version 0.1. There will be a lot of missing pieces and a lot of patch work as I find what the best way to design the library is. I envision rewriting sections that were poorly thought out. I think it would be good. Something that couldn’t be done with the official library shouldn’t really hinder me with the development of the library. The reason is that, for one, the library is alpha, so nothing is tied down as of yet, and two, not that many people use it, well at this point, no one uses it, so I don’t have to worry about an user base getting upset about API changes.

I have plans for each alpha version leading up to the stable release. This isn’t an exact milestone per say and subject to change. I think I’m going to continue develop as much as possible until the end of this month. I may not release 0.1 (I will tag it when I get to that point), but not create a release. Creating a release to me is providing a PHP 5.2 version. The more classes and code I write the longer it will take for each release to backport the library to PHP 5.2.x. It will be good practice at this the end of this month to do so.

It is actually a lot of fun, because I get to play with PHP 5.3, which is still in alpha. I also get to do a lot of experimental classes and put together a fluid interface pattern library. I also get to look at the adapter pattern some more. I’m going to explore the controller pattern in the library, because there are already so many libraries which do that already.

Possibly Related Posts: