http://matthewshafer.net I program Stuff Fri, 03 Feb 2012 21:59:14 -0500 en-us http://matthewshafer.net/02/03/2012/feedstock-and-ruby http://matthewshafer.net/02/03/2012/feedstock-and-ruby Fri, 03 Feb 2012 21:59:14 -0500
I have a friend who works with Ruby on a daily basis and he was showing me active record migrations and how simple they were. I was pretty excited as to how simple they were and spent quite a bit of time looking for something that was the same in php. I found a few projects but didn't feel like they suited feedstock that well. All I really wanted was the migrations as I felt it would streamline development for feedstock. I would be free to make changes to the database when I needed and would not have to worry about what version the user was on. I was left with two options, write my own migration program in php or use Ruby and the standalone migrations gem. The standalone migrations gem fit what I was looking for so I decided to use it. It also makes it a lot easier to support various different types of databases.

A second reason is that a few people I know have wanted me to learn Ruby, and subsequently Rails. This seemed like a good reason to add some Ruby to feedstock as I would learn a tiny bit about the language and see how things work. I could get into some of the things I find a bit funny, but thats probably because im coming from the java/c/php world.

I wanted to address the long time from the last feedstock alpha until now. Alpha 4 is still not done and I don't have any definite date set. I've worked on quite a few things in between the last alpha and now (various feedstock things and other projects) which you can find on my github page.]]> http://matthewshafer.net/04/22/2011/new-server http://matthewshafer.net/04/22/2011/new-server Fri, 22 Apr 2011 17:33:18 -0400 http://matthewshafer.net/04/14/2011/caching-changes-in-feedstock-alpha-3 http://matthewshafer.net/04/14/2011/caching-changes-in-feedstock-alpha-3 Thu, 14 Apr 2011 14:15:42 -0400
I was able to get rid of two separate cache backends by creating an interface called GenericCacher and creating a CacherCreator class. The GenericCacher interface defines functions that each cacher must have. The CacherCreator class checks to see if the currently loaded cacher is an instance of the GenericCacher interface. If it is an instance of GenericCacher then we know it is going to implement all of the functions in GenericCacher. By requiring each cacher implement GenericCacher I was able to structure my code so both forms of caching, static and dynamic, are supported by the same cacher class.

Now FileCache supports both static and dynamic caching, where it previously only supported static caching. This means that if a host doesn't support anything like APC or Xcache someone could cache either sql or fully generated pages on disk. I ended up having FileCache serialize and unserialize data when writing and reading files from disk. The nice thing with serialize is I can store arrays in files and read them back into an array with the same format, definitely comes in handy when the sql results are going to be arrays. Using FileCache is usually slower than using APC or Xcache (This is because those caching backends store data in memory) but it is usually faster than running without any caching.

One of the nice things about rewriting the way caching works is that it is now really easy to add support for new caching methods. One of the caching methods feedstock currently does not support is Memcached. The main reason for this is that I don't have a Memcached server to test things on. If I were to support Memcached it wouldn't be hard to get it added to feedstock. All I would need to do is add a Memcached.php file (and a Memcached class inside of that) that implements GenericCacher. Once there I would just need to set up the logic and then change $this->config['cacheName'] = 'something' to = 'Memcached' . There will probably need to be some changes to the way caching classes work because Memcached would need to take in a list servers it can connect to.

Something I might add to GenericCacher is allowing the constructor take in an optional array of options at the end. This would allow future caching methods (like Memcached) to take in custom options. These custom options could be a list of servers to connect to.

To sum things up the way caching is implemented in feedstock alpha 3 is greatly improved over previous versions. It is now easier to support new caching methods, easier to make changes to the way caching methods work (via things like GenericCacher interface), and easier to support the two (static/dynamic) types of caching data.]]> http://matthewshafer.net/03/25/2011/feedstock-alpha-3 http://matthewshafer.net/03/25/2011/feedstock-alpha-3 Fri, 25 Mar 2011 22:44:11 -0400
You can find it on my github repo. There have been a lot of changes to the front-end of feedstock in this release. As far as changes go most are going to be transparent to users, minus the new config format (there is a config.sample.php on github you can use to convert the old config to the new format). I will hopefully have some time over the next few weeks to go into more detail the changes that took place.

Some quick stats from Alpha 2 to Alpha 3 there were 50+ files with changes 3,400+ additions and 1,900 deletions.

I hope you enjoy it.]]> http://matthewshafer.net/07/26/2010/a-quick-update-on-feedstock http://matthewshafer.net/07/26/2010/a-quick-update-on-feedstock Mon, 26 Jul 2010 19:58:43 -0400
APC support. I figured that since APC is going to be bundled with php 6 I should support it, plus it's really good and we are currently running it here.

Lazy database connecting. So if all the needed DB queries are already cached we don't even spend time connecting to the database. The nice thing is that performance should increase but we don't know if the database is down until we actually need to get something from it. I have to possibly work out better errors for it, it currently uses trigger_error().

Lastly sitemap generation. Sitemap's are generated whenever there is a new post/page/category. They come in handy for web crawlers so they know every page that feedstock can show. Sometime in the future I would like to support siteindex's, they allow multiple sitemap's (sitemaps can only hold something like 50000 links).

Like I said before there was a bunch of behind the scenes changes and some mysql query changes (now that I understand JOINS). If you find any bugs feel free to contact me, you can find that info in the navigation right up ^^ there.


Oh and I should mention http://redmine.niftystopwatch.org has been taken down, you can find out why if you go there.]]> http://matthewshafer.net/06/29/2010/so-this-plugin-thing http://matthewshafer.net/06/29/2010/so-this-plugin-thing Tue, 29 Jun 2010 22:59:36 -0400
When I started working on feedstock one of the decisions I made was to not support plugins. It's not that I dislike plugins, because they can be really great. It's just that anyone can write them and it seems that the more you add the slower things get. Since feedstock is written in php and php isn't a compiled language (I understand there are things like phpc and hiphop that can compile php). So lets say someone comes to visit the site, I load all my "core" stuff then check for plugins and load those, then start running. If the plugins were to register onto things when when I get to that point we need to run stuff in the plugin (the plugin could have really bad time complexity O(2^n) would be bad but probably wouldn't happen) then go back to doing what we were previously doing. So for every plugin that is added it needs to be loaded and then wherever it registers we need to run it.

On top of that I would need to provide an interface to allow plugins to interact with the core of feedstock. I am not at a point where I feel like I could handle this. Then I would have to deal with possibly breaking things when feedstock was updated. When it's just me as the developer I would rather spend my time making cool things and fixing bugs (not that fixing bugs is super fun but hey things need to work).

In the end I would rather spend my time making the core functionality of feedstock pretty good, since I don't have an unlimited amount of time.]]> http://matthewshafer.net/05/21/2010/the-work-continues http://matthewshafer.net/05/21/2010/the-work-continues Fri, 21 May 2010 01:56:57 -0400 http://redmine.niftystopwatch.org(sorry if it takes some time to load). I would really enjoy your feedback on feedstock. Oh and feel free to contact me if you have any questions with it.]]> http://matthewshafer.net/05/08/2010/why-feedstock-doesnt-have-commenting http://matthewshafer.net/05/08/2010/why-feedstock-doesnt-have-commenting Sat, 08 May 2010 01:51:15 -0400 Disqus and Intense Debate to name a few. Those should be pretty simple to implement as it seems like they don't require any core modifications to feedstock code, they can be implemented at the theme level.

Another reason would be having to monitor commenting for spam. There are systems out there that help with that, akismet and Typepad AntiSpam. Even when I ran a small traffic blog spam still got through, and the amount of spam that was caught was pretty insane.

So maybe at some time Feedstock will support it's own commenting but currently there are reasons for me to focus development in other areas.]]> http://matthewshafer.net/05/05/2010/back-to-apache2-prefork http://matthewshafer.net/05/05/2010/back-to-apache2-prefork Wed, 05 May 2010 01:02:23 -0400
So I decided to run Apache in Worker mode and run php using fastcgi via mod_fcgid. On top of that nginx is sitting on the front-end serving up static content and when needed caching data. After setting everything up things were running faster, yet there was still a downside. I use opcode caching for PHP as it allows me to squeeze more out of my server. Now when running php via mod_fcgid having php spawn children is not a good idea as they aren't managed by fcgid and no requests are sent to them. Instead of having a parent php process and a bunch of children sharing opcode caches you have a bunch of parent php processes each with their own opcode caches. The biggest downside comes when you want to invalidate data in the caches, since each process has it's own cache if you invalidate something is is only invalidated in one cache.

This lead me back to using Apache2 in Prefork, since apache spawns children they all share the same PHP opcode cache. Since I have nginx sitting in front of apache serving up static content I am able to get great performance on static stuff. Now apache only gets hit when serving stuff like PHP.

After switching Apache back to Prefork I've actually seen higher performance out of Feedstock than I did before. The memory usage is about the same as before so its not like I lost out by switching back. The bonus is also that there is one opcode cache for PHP that all the Apache children can share.]]> http://matthewshafer.net/04/30/2010/now-with-pubsubhubbub http://matthewshafer.net/04/30/2010/now-with-pubsubhubbub Fri, 30 Apr 2010 01:49:39 -0400 PubSubHubBub. Today In class I was checking out how to get publishing working and it turns out it is pretty easy. When I got home I sat down and started working with it and ended up writing my own PubSubHubBub php class, ok well I could make it more generic but still it works!

Since there's two feeds that Feedstock can handle I need to send two separate notifications to the hub we are using (you can only use one hub write now, I *think* it is possible to have more than one hub). I opted to use multi_curl which hopefully saves some posting time as it sends both posts at the same time. Both the ATOM and the RSS2.0 feeds support PubSubHubBub in Feedstock. Going to http://matthewshafer.net/feed/ defaults to the RSS2.0 feed whereas http://matthewshafer.net/feed/atom/ goes to the ATOM feed. Anyway if anyone is having issues with the feeds you can always send me an e-mail.]]>