Wanting to give back to the open source community, I like releasing my work as open source software just in case someone else can use it too. A few months ago I released a few libraries (which I call “components”) and have been tinkering with them since then. After a bit of time, I felt like it was time to work on stabilizing them and having a 1.0 tag. I did another pass through all of the libraries and re-organized everything.
The re-organization resembles how the Symfony components are made available on GitHub. This should make it easy to add to your own projects, especially when using Packagist. The only exception is that the unit tests for each library are stored in one repository. The libraries are tied to the unit tests as submodules.
I just need to finalize the Log component I wrote, update both Event and Exception which rely on it, and I can finally release a beta version of everything. I will give it a couple months of releasing more betas and release candidates before settling on what would be a 1.0 release. I would very much appreciate input so that I can improve on them for your own use. The best way of doing this is to open issues in the respective repository.
The CODEAlchemy components:
I write this primarily for a friend in order to share my experiences and beliefs, hoping to ease some of the stress on her mind.
Finding the special someone in your life is a journey. For some, the journey is very simple and they find the perfect one for them right off the bat. For others, there is a little bit of leg work to be done, but their persistence pays off.
As a person floats on through life, they may find various people they loved or had a strong attraction to. For some, it may develop into a relationship. For others, those relationships do not work out. It is important to see these experiences not as failures, but as lessons in a person’s own tolerance.
Each passing relationship is something to learn from, not to mourn over. The relationship was never meant to last, but it was meant to teach you something about yourself. In essence, it is training for when you find your perfect match.
Someone out there is doing the same thing, and looking for you. Do not limit yourself to the world immediately around you. Do not forget that of the 6.8 billion+ people on Earth, there will be at least one perfect person in search of you too.
Do not give up, and do not choose the easy path. Doing so cheats yourself, and the perfect person searching for you, out of any true happiness you would have had. Remember that when ever you feel lonely or depressed, they do too.
We made a mistake. Over the last couple of days users brought to light an issue concerning how we handle your personal information on Path, specifically the transmission and storage of your phone contacts. As our mission is to build the world’s first personal network, a trusted place for you to…
This is why I use Path, I trust them more than I do Facebook. I wish my friends and family would understand the importance of personal privacy, and why Path is one in a long list of alternatives to Facebook. I only wish they had a web or desktop app for non iOS and Android users.
I micro-raged when I saw the first three characters of the bill’s serial number.
Last year I wanted to use the newly released Symfony framework to create my own web applications. As I perused through its source code and documentation, I noticed that there were a lot of concepts that I could learn and use in my own software. I decided to scrap all of my existing work and start clean using my new found knowledge. The result of that work are a few libraries I have developed, and some more I will be releasing later.
All of the libraries I have released are unit tested and have both usage and API documentation available as part of their repositories. I would be more than grateful for bug reports and suggestions for improvement.
The Log library, also named as the “CODEAlchemy Log component”, is a customizable log management library. I drew a whole lot of inspiration from Monolog, the logging library used by Symfony, and took it a little further.
The library is divided into four small parts:
Note that I will describe the default functionality the logging library will provide. You are not limited to these defaults! You can use the bundled interfaces to create your own classes to expand on what the library can already do.
Log entries are instances of an EntryInterface class. Instances of this class not only contain the actual log message, but a whole lot of other potentially useful information. Some of which include: severity, origin of the message (file path, line number, class name, method), as well as the date and time of when it was created. Instances of EntryInterface classes also support additional custom attributes in case even more information needs to be added (see Processor below).
Log entry processors are instances of an ProcessorInterface class. These classes make use of a log entry’s ability to accept additional information through attributes. The included processors allow you to add information such as current memory usage, current peak memory usage, and web information such as request URI, request method, and the client’s IP address.
Log entry stores are instances of an StoreInterface class. These classes are responsible for actually writing the log entry somewhere. The included store classes allow you to use any output stream, as well as a file.
Log entry managers are instances of an ManagerInterface class. Managers bring everything together so that you do not have to manually call all processor and stores on every log entry you wish to use. You simply add the processors and stores you want to use, and you just add log entries to the manager. The manager will take care of running the log entry through all of the registered processors, and then finally writing the log entry to all of the registered stores.
The Exception library, also named as the “CODEAlchemy Exception component”, is a customizable exception handling library. I created this library because I noticed a consistent pattern in the way I used errors and exceptions, and did not want to re-invent the wheel for each new web application I wrote.
The library is divided into three small parts:
Exception renderers are instances of an RendererInterface class. Renderers do as their name implies: render exceptions. The included rendering classes allow you to choose between rendering for CLIs or in HTML.
Exception logs are instances of an LogInterface class. Logs also do as their name implies: logging exceptions. The included log classes allow you to either log the exceptions using error_log() or the Log library I described earlier.
The exception handler is the class that brings it all together and actually receives the exceptions from PHP. You may only use one renderer and one log with the handler. Only one renderer may be used because it just does not make sense to use more than one. Only one log is used for keeping this simpler in the handler, but the log class itself may write to more than one log (see the Log library above).
The handler also provides a method to convert errors into exceptions. This makes for more stricter error reporting and will also provide error messages the same benefits that exceptions receive when this library is used. It’s not required that you use this method, but if you are serious about writing good code, it is a very useful thing to have.
The handler also takes care of not sacrificing stability over the features the library provides. If an exception is thrown by either the log or renderer, it attempts to recover and fall back to more reliable means of error logging and rendering. However, because errors cannot be caught, I suggest that you convert errors into exceptions so that those can be recovered from as well.
The Event library, also named as the “CODEAlchemy Event component”, is my implementation of the observer pattern. The added twist is that the library supports logging and the sharing of relevant data.
The library is divided into three parts:
Event subjects are instances of an SubjectInterface class. The subjects manage observers and notifies them when an update is available. The subject also doubles as a contain for shared data. The data can be accessed by using the subject instance as an array. A log may also be attached in order to log when an update is started, which observers are called and in what order, as well as the update process’s status.
Event observers are instances of an ObserverInterface class. The observers are on the receiving end of an update. They also receive the instance of the subject so that shared data can be retrieved and/or manipulated. An observer is where you would do all the work you planned on doing for a specific event.
Event dispatchers are instances of an DispatcherInterface class. Dispatchers manage a collection of subjects and will event trigger the update process for the specified subjects. A log can also be attached in order to log when subjects are attached, detached, and updated.
For the past 7+ years, I have had zero problems with GoDaddy. I did not care about their marketing campaigns or the comments made about GoDaddy. Business is business and GoDaddy was and is good at what they do. With the recent improvement they have made to their user interface, this makes this even harder.
Like many others, I have and am in the process of moving my last domains from GoDaddy. Their stance on SOPA is pretty clear cut. They apparently helped co-author the bill, and are specifically exempt from its ill effects.
It is also pretty frightening that politicians are ignoring professional advice from many important service providers. What is even more terrifying is that they completely ignore the obvious consequences of the bill, which is censorship.
It is very naïve to think that they either do not know or will not abuse the power the SOPA bill will provide. It does not take a smart man to know this fact. Every bill in the name of protecting anything has always been abused. Just take a look at the United State’s history of passing those bills, The “Patriot” Act chief among them.
Apache 2, PHP-FPM, mod_fastcgi -
Took me a while to figure out how to get this thing to work.
I ended up realizing that the default configuration for mod_php redirect all PHP processing to the module instead of FastCGI.
DocHub.io: CSS, HTML Documentation in a Clean, Searchable Site
Are you trying to run PHPUnit, but it just exits without doing anything? Hopefully, I think I may have an answer for you.
For me, a vanilla installation of PHP with PHPUnit will do nothing if one of your scripts cannot be parsed by PHP. You would never know this because the default INI configuration for PHP hides those errors. To know for sure, you should check the exit status after running PHPUnit.
kherrera@dev:~/git/myProject$ phpunit
kherrera@dev:~/git/myProject$ echo $?
254
The exit status may be different from yours, but it cannot be zero if it’s the problem I think it is. To fix this, you need to change the display_errors and error_reporting INI settings for your CLI PHP installation. Your settings should look something like this, just make sure you don’t do this on a production machine:
display_errors = stderr
error_reporting = E_ALL
Now when you run PHPUnit, you should see something like this:
kherrera@dev:~/git/myProject$ phpunit
PHP Fatal error: Call to undefined function badTaco() in /home/kherrera/badtaco.php on line 3
PHP Stack trace:
PHP 1. {main}() /home/kherrera/badtaco.php:0
Fatal error: Call to undefined function badTaco() in /home/kherrera/badtaco.php on line 3
Call Stack:
0.0001 317568 1. {main}() /home/kherrera/badtaco.php:0
The output will be different for you, but at least you now know why PHPUnit isn’t running. Once you fix the bugs causing the error(s), you should be able to run PHPUnit without a problem.
I have been having issues getting Eclipse 3.7 with PDT to work with the Marketplace client. I wanted to install it so I could install the Lion fullscreen plugin, but the instructions should work on any other OS.
You’re done.