Ever wanted to check up on your trusty BugLogHQ server to see whats going on with your apps on the go? Have an iPhone or iPod Touch? Well, today is your lucky day. I just pushed an update to BugLogHQ to include a custom web interface for the iPhone and iPod Touch. Even better, you can bookmark the app and add it to your Home screen and it will behave like a normal 'App Store' application.
One very useful feature of BugLogHQ is the 'Rules' feature. These are basically rules or conditions that get evaluated every time a bug report is processed and can be used to provide custom behaviour. Rules may be used for things like alerting you when some special condition happens; For example you can create a rule that will send you an email as soon as you receive a bug report with the words "stack overflow" on it, or to possibly send you an SMS message once the amount of errors on the last X minutes is greater than 100 errors, or well, you get the idea.
In this article I want to go over how rules are implemented and give a brief example of how to create your own rules and add them to your BugLogHQ instance.
The newest release for BugLogHQ is now available for download at RIAForge. This new version has lots of new additions and improvements that will make it even more powerful and easier to use.
Here are some of the highlights of the new version:
» Asynchronous processing of bug reports and rules. I think this is the single most important feature of the release, so I'll go into a bit of detail here. In the previous versions every time the listener received a bug from another application it had to parse the bug, add one or more records to the database and process any rules that were defined; although this implementation responded very well (even collecting errors for a 30+ server deployment on a really high traffic website), it was obvious that this approach was not going to be very scalable, especially if many rules were defined for processing. So, on the new version the receiving and processing of bugs are two independent processes; that way BugLog can receive a bug and return a response to the caller application almost immediately since there is virtually no processing done at that time. It's responsibility of another process fired at regular intervals to process all bug reports on a queue along with any rules that are defined and this process can now takes its sweet time to do whatever it needs to do without the pressure of having to return a response to the caller application.
*** THIS IS A REPOST OF AN EARLIER ARTICLE THAT GOT WIPED OUT ON A RECENT DB CRASH. ***
If you ever wanted to modify ColdBricks or BugLog, but didn't understood how these application were constructed; or if you just want to see yet another way of developing CF applications, then this post may be for you.
I just posted some pages describing the framework I use for developing CF projects. It doesn't even has a proper name, I just call it "Core" due to its simplicity and its minimalistic nature. The basic principle of this framework, and the reason why I choose to use it instead of going with more traditional offerings, is that it only focuses on one thing and one thing only: provide a formal mechanism for going from one page to another and for invoking actions.
It doesn't do any fancy things, no complex request lifecycles, no sophisticated caching, no extensive API, none; however, it does provide enough extension points to which I can hook any functionality that I desire on a per-project basis. Basically the framework consists on a Front Controller implementation, a base event handler and a few conventions for directory structure and nomenclature.
Anyway, you can find the code and read more about this framework by going to the Projects section or by going directly here.
I wanted to share a couple of news about the BugLog project.
First if you are using ColdBox, Tom Demanincor wrote a very nice tutorial on how to integrate bugLog as a ColdBox plugin. Check out his blog post here, it is very detailed and shows the code needed to make it work.
Also he raised an interesting point if you are modifying buglog to use per-application mappings. The BugLog distribution contains basically two independent applications. The main one is the server/listener part, which is the part that receives the bug reports from the applications. This is on the main bugLog directory and has its own Application.cfc. This application does not have a user interface.
The second application is the HQ application, which is the part that has the user interface and is where you get redirected if you just go to /bugLog in your browser. This is where you can see the bug reports and look at the pretty charts. This one also has its own Application.cfc and is located in /bugLog/HQ
So if you are defining per-application mappings programmatically on the Application.cfc don't forget that you need to set them up on both Application.cfc files otherwise you gonna find some weird errors.
Additionally a couple of people in the community reported a few minor bugs that needed to be corrected. The first one dealing with some component references not being created with the full path to the CFC and resulting in some errors. And the second one was that sending of bug reports via email was not working due to a missing setting.
To enable emailing a bug report that has been received you need to edit the /buglog/hq/config/config.xml.cfm file and set the contactEmail setting to the email address you wish to use as the sender.
I have updated the project in RiaForge with these fixes, so you can get the latest release from there. Here is the link.
This is a short post just to announce that version 1.3 of BugLog is now out of the beta phase and available for general download at RiaForge.
There are only minimal modifications from the beta release, basically some inconsistencies with the field lengths on the SQL Server scripts, but other than that the code is the same.
If you had any problem with the beta version and didn't report it before, let me know here or via the forum at RiaForge and I'll take care of it.
Enjoy!
Well, I've been busy today working in a ton of fixes for BugLog 1.3 and have now a second release of the beta for 1.3.
This beta fixes issues mostly with MSSQL and also other things that I overlooked (damn those last minute changes!!!) and never tested properly. Also I fixed an issue with the MSSQL database scripts and also another one with the rules processor.
The full list of bug fixes:
• BugLog was looking for its config xml files using the wrong name (now both xml config files have the .xml.cfm extension so that hey are hidden from direct browsing)
• Formatting of table names was not working in MSSQL
• Code to detect CF8 when inserting records was not working
• The process of obtaining the ID of the last inserted record was not working properly for MSSQL
• The SQL statement that performed a search on the log entries was using date parsing functions that were specific for MySQL and MSQL was failing. Now it uses the appropriate functions depending on the db type.
• SQL scripts were creating a wrong foreign key relationship (only for the MSSQL 2000 and 2005 scripts)
• Rule processing subsytem was not updated to use the new dao layer
I want to thank Joe Danziger from AjaxCF for all the help in testing and reporting several bugs specially related to MSSQL code.
Here is the new beta, so feel free to download and play with it.
I've been working this weekend on an update to BugLogHQ, mostly to fix several issues with database access.
Here is the beta release for BugLogHQ 1.3. Download, unzip, try it out, and let me know any bugs you find.
The changes for this release are pretty much all internal to the functioning of BugLog; basically I re-did the way the application interacts with the back end data storages; also added some caching functionality that will improve the performance of the listener and finally made some changes to the main BugLogHQ application (yes, the one with the pretty charts :) ) to improve the performance especially when you have already a lot of bugs.
Enjoy!
I want to let everyone know that I have released my first Adobe AIR application. It is a small desktop client for BugLog . It is called "BugLogMini" and I just can stop being impressed by the possibilities that the Air platform brings for app development. First, here is a screenshot of the main interface:
Read on for more info...
Well, it's official, the new release of BugLog is now available at RiaForge. I know I just recently released version 1.1 but I was so excited about the new Rules system that I wanted to share it with anyone that is using BugLog. You can read more about the concept of rules in BugLog here.
The new version includes the rule processing functionality as well as an interface within the BugLog admin for users to manage the rules. New rules still need to be created manually by creating the rule cfc, but the interface allows users to define/modify/remove instances of rules.
Since this is brand new functionality I'm calling this release a "beta" to see if any bugs make their appearance, as well if there is any feedback from the users (anyone? hello?? :) )
Well, check it out and let me know your thoughts.
