You Are Here

Month: October 2018

Randy

WordPress vs Everything Else – Why you should not build your own blog

Wordpress

Being a web developer, the idea that I would use a blogging platform always made me cringe a little bit. I mean, why not. I had the skills to create my own blog that I could customize exactly how I wanted. And thats where I started originally.

I wanted to learn a new language, Ruby on Rails, and what better way to start than follow one of many “How to build a blog with Ruby on Rails” posts that were littered across the internet at the time. So I did that for a while, and back then (circa 2006-ish) there wasn’t much in the way of deployment and server-ease like Heroku, so I had to manually do all that myself, with FastCGI and eventually Mongrel.

 

I quickly realized that all the customization that I wanted to build, I no longer wanted to build. I just wanted a place to share some ideas and not worry about the management of another web application. I was already doing that in my day job. At this point, I decided to use WordPress, but this wasn’t my final decision, I would come to find out.

I had started using WordPress for a while, but again, the developer bug crept back in. I wanted to find something else that wasn’t so “WordPress-y”. I tried some other things like Joomla, Typepad, Jekyll and other static blogging codebases. I eventually settled on using Bolt, which is another PHP based blogging platform. I have no idea why….

I used that for a while and finally got tried of the lack of community around it and some customizations that I missed, that were available with WordPress out of the box. After battling with that for a while, I decided to move back to WordPress and import all my data back into it. I think this is where I’ll live now and its just so flexible and easy to just start writing.

I am in no way saying, don’t write a blog if you want to learn a new language. It’s a super simple idea that I think anyone can grasp, and you don’t want to be overwhelmed while learning a new language. I would just recommend to not bother using it for your official, public blog that you want to write on all the time.

So at the end of the day, I am not a super fan of having a PHP based blog, when I mostly code and write about Ruby on Rails code, but the fact that I pretty much never have to dig into the internals of WordPress, makes it worth it in the end.

You May Also Like

Randy

AppPerf Latency Bands with color schemes!

AppPerf, Rails, Ruby

I haven’t posted lately about any updates I have been working on in regard to my open source application performance monitoring tool call AppPerf. I have been trying to get some time here and there to work on and improve it and add new features that would be useful. I am happy to say that I finally added a new chart on the overview page that should hopefully make it easier to identify when you are having an issue in regards to the performance of your application. I got the inspiration while reading about query bands on the VidixCortex site. Coincidentally, I have decided to call this new visualization, Latency Bands, as they are measuring the latency across different percentiles of data.

Previously, I was using two separate graphs to represent what I think I am able to show in one graph. I also think its much easier to identify when an issue has risen. First I will show what was previously being displayed on the page:

As you can see, I was showing a Latency and Latency distribution chart. The Latency chart was showing 50, 75, 90, and 95th percentiles. Likewise, the distribution graph was showing, well the distribution of requests across all 100 percentiles. At first glance, its hard to tell what is actually going on here, and with AppPerf, I want to make is extremely easy and quick to say, “Hey, I see a problem.”. Also, while these particular percentiles are helpful, what about the 95th and up percentiles that you are missing. Those are also important. We don’t know if the 100th is 5000ms,50,000ms, or even more. Not that helpful.

Now lets introduce the Latency Bands chart:

Quickly looking at this chart, you can see that something is going on at about 11:39 AM, as indicated by the red spike in there. The way this chart works is that it groups the latencies into 10 buckets based on their latencies. As the latency increases for that bucket, so does the color. The color range goes from blue to red, as more requests are grouped into each bucket. If you want to see the breakdown of the latencies, and how many requests there were, you can mouse over each data point and view the following:

Once you find a spike in your latency, you can then drag over that range to zoom in farther, and create a time scope that shows you what was going on with each of your components at that time. Hopefully this feature will allow you to identify more problems quickly, and determine how to fix them!

Shoot me some comments below if this was helpful!

Thanks

You May Also Like