Writing Java Servers With GUI

Posted by Jacob Santos on February 19, 2011 Comments Off

I’ve only been programming Java for a week, but I’ve learned quite a bit in that time. Well, mostly from making a lot of mistakes. Generally, most mistakes are made during the learning process with a new language. Trying to build a damn GUI Application with a multithread proxy server was one of those mistakes.

Let me explain. I’m using Swing or more accurately a Swing Framework that comes with Netbeans, but not the Netbeans platform. One thing I’ve discovered through trial and error and then doing some researching, is that Swing only allows you one thread. Well, this isn’t completely accurately, but for all purposes, if you attempt to create a Thread and attempt to access any Swing object, your application is going to crash and burn. Also, at any point, your thread might run and deadlock the GUI thread causing your GUI application to become unresponsive.

So yeah, if you want to use Threads with Swing or really any GUI framework, except I think you might be able to get away with it if you are using OpenGL, but it is tough building a working GUI using OpenGL. I’ve came to the conclusion that I was doing it wrong half way through the entire process. The reason I didn’t scrap my current work was that I still didn’t have the proxy working correctly and I didn’t want to have to completely rewrite the entire application. I didn’t think I had the motivation to rewrite everything again and not even have a working product.

Well, I have both a working product and a GUI application. The solution was to use SwingWorker for the threads which basically adds the Runnable to Swing to run when it pleases and won’t lock the application. The problem remains is that I still need to create a thread to run two tasks side by side. A better description would be to say that I need to thread something that I don’t really care about when it finishes and appears to take forever to complete. It is currently slowing down the Proxy and there isn’t much I can do about it, unless I wanted to create another SwingWorker, but the problem is that I want to queue the messages sent to the thread and handle other tasks.

I want to create a Timer which will shut down the thread and close the connections if nothing had been received during that time. Currently there are stability issues with the GUI application not accepting any connections after the Server drops the connection or the application is closed.

What I thinking about doing is creating a new thread whenever a client socket is received, which will start a timer thread. There is currently a thread for the client to the server and another thread for the server to the client. What I’ll end up adding is another thread which will manage the messages sent to it and also eventually handle an OpenGL window application provided that it is allowed.

I’m thinking about keeping the GUI application. I can finish work on the separate process for the Proxy server and have the GUI manage the options and fork the Proxy server from the application. It would work almost exactly as it does now, but just work better and faster.

Possibly Related Posts:


DragonU Bug Tracker Dev – Milestone 1

Posted by Jacob Santos on February 6, 2011 Comments Off

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

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

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

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


State of Bug Trackers

Posted by Jacob Santos on January 14, 2011 Comments Off

It is disappointing to me that the best Bug Trackers out there are web applications that you can’t access the source to. It is disappointing, because these web applications often lack some feature that make open source bug trackers great. The best of these that do combine the best of both worlds require payment and often have more features than most require.

I think the problem has always been that bug trackers have been built by programmers for programmers based on specifications that the programmers thought others would require, need or comprehend as useful. There are basic features for organization of bugs or tickets, but most of the time these are made for programmers. An user doesn’t really know what milestone or version the ticket will be completed, they might not even care. They probably don’t know how the administrators define each component and I doubt most really care.

The key element of most web bug trackers are that they are simple and easy. They remove most of the cruft and useless features that plague open source and other more complicated bug trackers. The break it down to the fundamentals of tracking bugs and leave you to have at it. Most of the time this is all you will need. When you get to the point where the basics are no longer cutting it for you, then either more features are being offered by the service or you move on to a more advanced platform.

I want something like this in an open source product that can be easily and quickly extended. I want something that takes the best of Trac, Get Satisfaction, 16 Bugs and maybe some of Fog Bugz.

Goals

The goal is to look at what makes these web applications great and include them in one package for people to use and hopefully extend. The goal is to also allow for enabling and disabling features as they are needed. If all you need is a 16 bugs (which is really more of a Basecamp clone), then well, that is what the basic package will be and you simply don’t enable any of the other features.

Features like roadmaps, components, reports, searching etc from Trac can be enabled, customized and configured later. However, what the web application will never be is anything more than a simple, but extendable bug tracker. There won’t be a Wiki, you would instead link to one, but I do hope to have some support for built-in linking of wiki, similar to the Trac feature.

Get Satisfaction

Looking at Get Satisfaction, I can really see why it will become popular in the future for a bug tracking web application. It is simple. Really incredibility simple, but well there are some navigation problems, but they are so minor that navigating the web site after the initial learning curve is not an issue.

It does what bug trackers should have been doing and really, I think you have to see it in action to realize its effectiveness. It allows you to not allow list problems, but also questions, request features and give praise. I think why it is so great needs a little bit of explanation, in case you don’t realize it already.

Why is giving praise important?

It tells the developers what people think they should be working on. It tells the developers and people making plans for the next release what features really made a person’s day; the one feature that sold the product for them. It also continues motivation for open source projects where no money is being made. It is really kind of depressing to read over defects all day, but with this feature on the site, people can tell you how much you helped them and that they care.

Why so simple?

If you think about it, what does the customer or user really care about? They really only care about telling you what the problem is and then leaving. Thinking about it some more and Trac is really setup to be confusing. How many people know which component a ticket belongs to? 1 or 2, 0 if the person who set them up was just winging it. How do you set the component when the ticket might belong to several? Throw darts most likely. What about the roadmap? Everyone thinks their ticket should be completed before the next release, but how often does that happen?

The power of Get Satisfaction is that it doesn’t burden the user with the minute details that really only the programmers care about or even know. It allows the customer or user to get in tell you about their problem and leave. In some ways Lighthouse is extremely similar, but mostly geared towards only defects and features with a bit of Trac thrown in for good measure.

I do like the bit about Giving Praise, along with asking for features. I’m thinking about including it. It won’t be that difficult to add and will work similar to everything else. It will just be a matter of allowing the administrator to disable it if so desired.

Problems of Get Satisfaction

I think Lighthouse solves many of the organization problems with Get Satisfaction. The major and only problem I can see with Get Satisfaction is the lack of milestones or separation of tickets. It is just one big list and when you have many tickets, praise, and feature requests, it can be a little overwhelming to go through them all. The other problem is the matter of duplicates. It is either difficult or impossible to mark something as a duplicate of something else.

Project Management

The strength of Fog Bugz is its project management and well, their other features as well. The initial version, I’m not going to focus on Project Management or Agile features, unless more time comes up.

I do think that this is what Trac is lacking. It is difficult to get metrics on what people want, on what people have done, how close the project is to being completed, etc. Reports and graphs are one aspect of this. The other is figuring out what programmers should focus their time on.

In my product, I want to initially focus on completeness of bug and feature tickets. I want to include ticket dependencies for features and bugs. I want a metric for whether a bug or feature is complete and for this I want a report that tells programmers which tickets they should be looking at.

Reporting

Ticket Completeness

The term ticket completeness is the workflow of the ticket from the initial report from the customer or user to the time is fixed or included into the project. It does not include tickets that are closed for being invalid or another reason.

  1. How Detailed is the Report? Does it include a detailed or proper description? Does it include correct steps to reproduce the issue? Does it include a workaround? Does it include Expected event -> Actual event descriptions?
  2. Does it have Attachments? Does it include a patch, a prototype, screenshots and, or other helpful files for reproducing or understanding the problem or feature?
  3. Does the ticket have comments? Are the comments helpful, debating the issue, or querying for more information? Do the attachments have comments, requests for feedback? Have the patches or prototypes been accepted?
  4. Does the ticket, defect or feature, have up votes telling the programmers what the users and customers care about?
  5. Has the extra information been completed: things like roadmap, version, OS, etc
  6. Time the ticket has been active, time the ticket has been opened, time the ticket has been stale.

    In a perfect world, every ticket will receive feedback within 24 to 48 hours. Whether it is a comment saying the ticket has been looked at and, or reviewed or a patch has been submitted. It is possible to include some of these feedback mechanisms into the web application. Whether the ticket has been looked at will include whether the core team has looked at the ticket or patch or whether a trusted member has looked at it or if someone else has looked at the ticket. These are easy features to include and might have some pay off for the reporter.

    This is really to tell the programmers which tickets are not receiving proper attention given the other criteria. It will also inform based on how complete the ticket is. If a ticket has a patch and the patch has not been reviewed, then why not based on a given number of days?

Giving programmers and contributors information to make wise decisions.

The programmers managing the project and the contributors should be able to see which tickets are being addressed and how well. They should also be able to quickly find tickets that haven’t received proper feedback and tickets that can possibility go into the next release.

I think this is the first step to project management features. The reports will be built-in, but completely optional. The emailing to the reporter on updates will also be optional and will be a single check box. The key will be to gradually give the reporter the impression that their ticket is being addressed and help the programmers address tickets.

Possibly Related Posts:


Database PHP Library and Fuzzy Logic PHP Library

Posted by Jacob Santos on November 6, 2010 Comments Off

I’m almost finished with the hard part of the HTTP library and the Hook library is almost complete as well. The next two projects are currently in the planning stage to be started once those two libraries are complete enough to be used in projects. I want to develop a ORM / Active Record Database Library to understand the workings of other database ORM and Active Record libraries. I also want to work on a Fuzzy Logic library for PHP game development.

Fuzzy Logic Library

I think that if there was already a Fuzzy Logic library for PHP, I probably wouldn’t even attempt an implementation. Given the math involved, I’ve been putting this off for quite a while. It has been almost 4 years since I wanted to do this. I believe I’ve progressed far enough with my programming skills and also understanding of what is involved with Fuzzy Logic to attempt it.

I don’t believe the initial attempt will be usable. I also think that I’m missing some key parts for understanding what exactly is part of the implementation of Fuzzy Logic systems. Reading what little I’ve found, there appears to be math that the authors assume that I should already know.

I’m going to start development of the class structures based on how I want the implementation to work. I believe that much I do understand, even if I am missing details. If I’m still missing information and the unit tests are not working, then I’ll have to buy several more books in order to complete my education. If I have to do that, then I’ll be charging for using the library to earn back some of the money I spent. If I don’t, then I’ll probably buy one or two of the books just be sure I didn’t miss out on features that people expect, but the library will be free for all to use.

I’m not exactly sure, I might be able to complete certain math related implementation details not dealing with set theory. I think that is part of it really. The graphing equations are really just geometry and I’ll simply need to look up the formulas for those and implement it in the library.

ORM / Active Record Database Library

I don’t like how other database libraries implement ORM and I want to development my own to see if how I think it should be implemented is even possible or feasible enough to be implemented. I want to keep the library simple, but feature complete enough that I could use it in my own projects. I believe that if I were to do a public project, that I should use another database library.

I do want to spend the time to learn how ORM is implemented and develop my own database library. I also hope that this time, the library I write actually works. The other attempts either were shit or too convoluted to even try to complete.

Possibly Related Posts:


New HTTP Library for PHP

Posted by Jacob Santos on September 14, 2010 2 comments

I’ve been developing a HTTP library for PHP on and off for the past 3 months. The motivations is to create something that should have been written for WordPress from the beginning. I think the HTTP functionality is okay for what it is supposed to be, but there are design limitations that this new library seeks to address.

For one, the ability to process headers without having to hard code the functionality into the library. Also, it removes all dependencies from WordPress. Really, I believe some of the hacks in the current HTTP API in WordPress should be dealt with in a better way. There will still be possible to do many of the things WordPress has with the hacks.

I’m also rewriting quite a bit of header processing, not only because some of the current code I don’t hold copyright to, but also to take advantage of PHP 5.3 and to fully conform to the RFCs.

You can find the code at Git Hub.

Possibly Related Posts:


Easier APIs for WordPress

Posted by Jacob Santos on January 28, 2010 1 comments

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:


Libraries Should Use Liberal Licenses

Posted by Jacob Santos on January 25, 2010 1 comments

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:


Media Matters: A Watch Group For Conservatives

Posted by Jacob Santos on December 21, 2009 Comments Off

If you read Media Matters, then the only conclusion one can come to is that Conservatives and Republicans are evil to the heart and soul. Whom are bent on world destruction, travesties, and generally would kick kittens because their so damn cute (albeit not always good, but I guess cute is good in a way). As a disclaimer, I haven’t really read that much on the web site, but it appears that they don’t often talk about liberals or democrats all that often, if at all.

To be fair, it isn’t as if Conservatives are any more “righteous” in their descriptions of the so called evil Left. It seems that to the Right, the Left is evil and wants to ruin the country and the Left likewise thinks the same of the Right. I will just say that they can’t both be right, but at least the bickering is entertaining. Quite frankly, I think both sides are doing a disservice to their side by polarizing each issue. Any layman should be cautious to take any side lest be associated with that side evermore.

I haven’t actually read any conservative blog, but I would assume the same tactics used on Media Matters applies as well. The tactics and proofs are far too effective at shutting down any opposing side to not be used. Using logic, reason, facts, and proof in a unbiased fashion isn’t as sexy as ad hominem attacks and using sources that are also biased towards the same opinion.

You see, attacking someone’s character is effective, because it puts the burden of proof, in most peoples’ eyes, on the character being attacked. In this the straw man side steps the issue by forcing the character being attacked to disprove the accusation and then try to disprove the other points made in the articles. The best claim is to say that since someone or some group took money from the oil companies, then they can’t make any argument against climate change or global warming.

While it may or may not be true that receiving money from a particular group that may lean a certain way in the research findings, it true of any group that receives money. If the pretense is that a group that receives money from a group believing a certain way is corrupted in their findings, then many of the research groups that receive any funding from outside sources are contentious. There was a very well written study about this very topic on Watts Up With That website, but I don’t believe Media Matters would ever consider that site as a valid source, given that they actually use facts, statistics, unbiased reporting (for the most part and I would say far more than whats on Media Matters), studies, evidence, and research to further their claim. Alas Watts Up With That website’s lack of frequently attacking someone’s character because they don’t hold the same belief wouldn’t make them a news source that Media Matters could use.

My perspective of the site, is that it wants to either preach to the choir or get the Independents who haven’t fully researched both sides of the issue or who are leading towards the mindset of Media Matters anyway to follow Media Matters. Researching both sides of the issue is slightly difficult and I do respect that Media Matters at least gives you the reference material to decide after reading the opinion piece. Often when they do give the full transcription or article they are referencing, the question is often, “Why is this a big deal again?” and sometimes they take jokes, sarcasm, and tongue-in-cheek out of context to further their claim.

Holy shit would they have a field day with me if I ever got into political writing. Of course, I don’t believe they would bother, because they go after the big names who people actually might listen to and read. Furthermore, I don’t really care about politics to write about it often. I just think that when you read something from Media Matters and its sources, you should be wary and do more research to get the full story.

Possibly Related Posts:


Paying Off Debt Revisited

Posted by Jacob Santos on December 6, 2009 Comments Off

I don’t think I posted the other detailing my plans because it is largely personal and many people shouldn’t know. I post some things for my benefit to see how well my planning went.

Paying Bills

I’m paying most of my bills using my bank’s bill pay. Now I don’t have everything on this. My insurance, cell phone, mortgage, and utilities are not using it yet. I think I can move my insurance to the bill pay, but I’m not going to worry about it. Most of the bills were paid by bank to bank and it causes problems when you forget that it is coming. With the bill pay, I can see exactly how much money is going to whom and when. Also, my bank will hold that amount so I won’t be able to accidentally spend it.

Automatic Savings

I’ve been saving for the past 4 weeks and while the amount is still fairly small, it is a decent start. I no longer consider that amount part of what I have, so I don’t feel like spending it. I’m going to be using it a lot more in the future, both to pay off my current outstanding debt and to make purchases in the future. I’m going to take the approach of saving up the money before I buy something, so that I am very rarely buying something with a credit card.

The reason I’m saving cash instead of paying off more cards is so that I’ll have that money in case I need it to pay other bills. If I use it to pay credit cards and then have to use that same credit card to pay other expenses, then I’m not getting ahead. At least it provides a cushion to prevent me from having to use credit. At some point I hope to save $200 to $300 and I should be able to after I pay off all of my credit cards. My goal is to eventually have about 6 to 8 months of salary in the bank in the case of emergencies. In this way, if something bad happens with me, my house, my job, etc that I won’t be in a position where I have to sell body parts to pay the mortgage.

Paying Credit Cards

With the amount of savings I have, I should be able to pay off one credit card with a small balance in about 3 weeks. I am going to wait another 4 or 5 weeks, so that I can still have enough savings to start on other projects. With the one credit card paid off, I’ll only have to worry about 3 more. The only problem as I see it is that paying this card off will only give me an extra $50 to $75 a month. However, I suppose it will lighten my mood having one less card to worry about.

The credit card with the highest balance will be paid off in 36 to 38 weeks or 8 to 9 months. I may get this card down to a thousand and focus on other cards. The two other cards, one is the second highest, but is a store card, so I’m more concern with keeping it in good standing and then waiting until the other cards are paid off before focusing on it. I made the mistake of paying too much on that card to only have no cash left over and had to resort to using my other credit cards. I’m a little bit wary of repeating that same mistake.

The good news is that one company has dropped me, so after I pay off two cards, I’ll no longer have that company. I’ll be dropping two more credit cards. This will affect my credit score a great deal, however, I feel that with the house, the one credit card, zero balance on all of my accounts, and good credit history that I will be able to get new cards of moderate balances and with APRs and terms that will be far better than what I’d ever get with the ones I have now.

Extra Money

I’m going to work on several projects that I’ve been putting off for a number of years now. I believe that when these projects are completed that I’ll be able to pull in some money. Albeit, it most likely will be zero to extremely small amount a month. However, it is far better than what it is pulling in now and anything is better than nothing. I have the motivation to work on these projects and I think that when a few of the cards are paid off that a few of the projects will also be completed.

Well, I plan on taking shortcuts to allow for the projects to be completed sooner. They might not be done in exactly the fashion I would have hoped, but at least they will be done. I plan on revisiting certain elements once they are complete, so that they can be optimized and perhaps sold for money.

Possibly Related Posts:


Why Writing Documentation Wasn’t a Waste of Time

Posted by Jacob Santos on November 14, 2009 3 comments

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: