Recently read "Rework". Very quick read and very good. It was recommended by Brad Feld on his blog and that is why I picked it up. Well worth the read.
https://www.amazon.com/gp/product/B002MUAJ2A?ref=myk_orders_title
Saturday, March 27, 2010
Monday, April 20, 2009
Cleaning House
I love moving into a new place. It forces you to reevaluate the things you own: the items that are super important to you and must be moved, the items that are a nice to have and can go or stay, and the items that you don't really need or want and can throw away. When I come out on the other side of this process I always feel lighter and more organized.
So, I've decided to do a little house cleaning with the RSS feeds I consume. Luckily I've been using GoogleReader for the majority of my blog reading. This means I can easily tap into Trends to see what feeds are important to me and which ones can go.
_1240228754338.png)
Here are the results so far:
1) Unsubscribed because the feeds were inactive (5)
2) Feeds that had apparently moved and were stale (3)
3) Feeds that appear stale but I'm giving the benefit of the doubt because of the content or who the blogger is (2)
4) Feeds that I no longer have an interest in (1)
If you are an avid blog reader I highly suggest doing this. It reminds me of the Jack Welch (GE) management strategy of 20-70-10 (or something like that). Where each quarter he asked his managers to identify the 20% of their team that are A players, 70% that are B players, and 20% that are C players. If you landed in the C players category for too many consecutive quarters you would be gone. This gives someone new a shot to come in at that level and work to move into the B/A group.
I am looking forward to finding new blogs to fill in the gaps created by letting some of my C players go.
So, I've decided to do a little house cleaning with the RSS feeds I consume. Luckily I've been using GoogleReader for the majority of my blog reading. This means I can easily tap into Trends to see what feeds are important to me and which ones can go.
_1240228754338.png)
Here are the results so far:
1) Unsubscribed because the feeds were inactive (5)
2) Feeds that had apparently moved and were stale (3)
3) Feeds that appear stale but I'm giving the benefit of the doubt because of the content or who the blogger is (2)
4) Feeds that I no longer have an interest in (1)
If you are an avid blog reader I highly suggest doing this. It reminds me of the Jack Welch (GE) management strategy of 20-70-10 (or something like that). Where each quarter he asked his managers to identify the 20% of their team that are A players, 70% that are B players, and 20% that are C players. If you landed in the C players category for too many consecutive quarters you would be gone. This gives someone new a shot to come in at that level and work to move into the B/A group.
I am looking forward to finding new blogs to fill in the gaps created by letting some of my C players go.
Wednesday, November 5, 2008
Thoughts on tweet: "drupal vs. clearspace vs. dotnetnuke... and go."
Context: This is a response the tweet posted by @ographer. I've worked extensively througout my career with many open source frameworks. PHPNuke directly and Drupal directly. However, I've never worked with the Clearspace.
Pros
1. In a short time you can demo a lot of functionality...people will like that. (traditional check list of features)
This is especially true if the person making the buy decision is a "higher up" who won't actually use the tool. If an engineer, UX designer, or potential heavy user of the system digs a little deeper I think they would have a similar response to the one I rant about below.
Cons
1. Most of these tools feels like an open source project.
The following is a major rant about what it means to "feel like an open source" project.
Basically, most of these projects start out as home baked CMS (Content Management System) tools developed by a freelance developer. Why? Because these guys are doing webdev work on the side or full time, and they love doing the tech work but hate getting bugged by clients to update content, tweak this color scheme, add this little bit of functionality, etc, etc. for only marginal additional revenue. So, they build a system where they can put control into the hands of their clients and it works well in the beginning when there are only a few thing the end user has to configure/manage but it eventually balloons. The people who start these open source CMSish projects are usually coming from the scenario described above and have the mindset, "this job would be great if it wasn't for the clients".
What this means to the end user and potential purchaser of one of these products/services is that there is A LOT to manage. If you get into using one of these tools to build a community you'll notice admin interfaces with tons links. Translation, steep learning curve. You'll also notice that whenever you want to add a new piece of functionality (e.g. E-Commerce) you MUST KNOW to look for that external plugin module, load it up and configure it. To really do this you might have to actually go out to the web, search for the module you want, download it, load it into the framework's core, etc. etc....yikes. The end user is not going to like this when trying to make the community work for them.
The main point I'm making here is that these tools tend to be designed to make the developer's life easier...this makes sense when you consider how these projects start out. The other point to make is that within each module these engineers are going to make assumptions in order to make their life a little easier....the result is extremely complex admin interfaces and you'll notice that once you try to do anything above and beyond the basic functionality. One of the things that blows me away about our platform, HiveLive, is the architecture underneath. Actually, that is one of the main reasons why I joined the team. We don't make any assumptions about what the end user may or may not want. This gives us more flexibility than any other system. Although we also have a decent amount of admin interfaces right now, our architecture makes it easier for us to identify patterns and suggest prepackaged configurations to users attempting to admin the system...some of these open source tools are going to have a difficult time doing this because of the underlying architecture. The main point I'm trying to make is that our platform has been designed from the ground up with our users in mind while most open source tools of this nature are developed (notice I didn't use the word "designed") in order to make the engineer's life easier...they hate getting bugged by clients.
Pros
1. In a short time you can demo a lot of functionality...people will like that. (traditional check list of features)
This is especially true if the person making the buy decision is a "higher up" who won't actually use the tool. If an engineer, UX designer, or potential heavy user of the system digs a little deeper I think they would have a similar response to the one I rant about below.
Cons
1. Most of these tools feels like an open source project.
The following is a major rant about what it means to "feel like an open source" project.
Basically, most of these projects start out as home baked CMS (Content Management System) tools developed by a freelance developer. Why? Because these guys are doing webdev work on the side or full time, and they love doing the tech work but hate getting bugged by clients to update content, tweak this color scheme, add this little bit of functionality, etc, etc. for only marginal additional revenue. So, they build a system where they can put control into the hands of their clients and it works well in the beginning when there are only a few thing the end user has to configure/manage but it eventually balloons. The people who start these open source CMSish projects are usually coming from the scenario described above and have the mindset, "this job would be great if it wasn't for the clients".
What this means to the end user and potential purchaser of one of these products/services is that there is A LOT to manage. If you get into using one of these tools to build a community you'll notice admin interfaces with tons links. Translation, steep learning curve. You'll also notice that whenever you want to add a new piece of functionality (e.g. E-Commerce) you MUST KNOW to look for that external plugin module, load it up and configure it. To really do this you might have to actually go out to the web, search for the module you want, download it, load it into the framework's core, etc. etc....yikes. The end user is not going to like this when trying to make the community work for them.
The main point I'm making here is that these tools tend to be designed to make the developer's life easier...this makes sense when you consider how these projects start out. The other point to make is that within each module these engineers are going to make assumptions in order to make their life a little easier....the result is extremely complex admin interfaces and you'll notice that once you try to do anything above and beyond the basic functionality. One of the things that blows me away about our platform, HiveLive, is the architecture underneath. Actually, that is one of the main reasons why I joined the team. We don't make any assumptions about what the end user may or may not want. This gives us more flexibility than any other system. Although we also have a decent amount of admin interfaces right now, our architecture makes it easier for us to identify patterns and suggest prepackaged configurations to users attempting to admin the system...some of these open source tools are going to have a difficult time doing this because of the underlying architecture. The main point I'm trying to make is that our platform has been designed from the ground up with our users in mind while most open source tools of this nature are developed (notice I didn't use the word "designed") in order to make the engineer's life easier...they hate getting bugged by clients.
Saturday, October 25, 2008
Simple Rule of Blogging
As an avid blog reader I've come to the conclusion that the perfect blogging style is:
1. Know your goal, you want people to read and comment/interact with your blog.
2. Item #1 then leads to a posting strategy I like. Short, concise, on message posts during the week. Leave the longer, big picture, pontificating posts for Sat. and Sun.
3. Respond to the people who leave you comments.
Simple and easy to follow.
1. Know your goal, you want people to read and comment/interact with your blog.
2. Item #1 then leads to a posting strategy I like. Short, concise, on message posts during the week. Leave the longer, big picture, pontificating posts for Sat. and Sun.
3. Respond to the people who leave you comments.
Simple and easy to follow.
Tuesday, May 20, 2008
Back to the Blogosphere
My recent hiatus from blogging has hopefully come to an end today. Getting started blogging is analogous to dieting. It started off very strong and even produced some pretty good results. Around month six the new began to wear off and the distractions of everyday life reclaimed my attention.
Well, just like dieting, to get back on track I must hunker down and become disciplined about the process. Before I was asking myself "What can I write about today?". That kind of focus made it easier for me to miss some days, and then eventually weeks and then months. So, I am now going to write at least one post a day during my morning commute. My focus has shifted to the process, not the content. I guess I'm going to need one of those shaded screen overlays for my laptop. Do those things really work?
Well, just like dieting, to get back on track I must hunker down and become disciplined about the process. Before I was asking myself "What can I write about today?". That kind of focus made it easier for me to miss some days, and then eventually weeks and then months. So, I am now going to write at least one post a day during my morning commute. My focus has shifted to the process, not the content. I guess I'm going to need one of those shaded screen overlays for my laptop. Do those things really work?
Wednesday, March 5, 2008
YUM vs. RPM
From an article I found while Googling "how to create YUM packages":
"yum sits on top of rpm, and handles dependencies. For example, say you want xpdf. You get the package for xpdf and try to install it. rpm whines that it has an unsatisfied dependency, say some library you've never heard of (part of openmotif, but you don't know that), and gives up. You go get the appropriate package(s) and try again. This can get to be a pretty deep recursive process.The program yum handles all that for you. You type at the command line:
The program then pulls what it needs from the repository, figures out the dependencies, tells you what it needs to do to install xpdf, and asks permission to go ahead, like so."
Sunday, February 24, 2008
REST API vs Query API
I think I have finally grasped the concept of the term "REST API"! Here is the article from AWS that helped me finally understand.
Unfortunately, for a long time I considered an API available via HTTP requests to be a RESTful API. I always new that the basics of REST were centered around placing the intention of your request in the HTTP headers via PUT, GET, POST, DELETE, etc. But when I would see APIs like GoogleBase, AmazonSQS, Facebook API, etc. I just reused the term "REST API" to describe them because I'd never heard it explained in another way.
Today it became clear to me the difference as I came across the term "Query API". A query API doesn't try to convey intention using HTTP headers like a RESTful API does. A query API simply says "hey put all the information you need for this request in the request itself". Personally, I prefer query APIs. Lets look at a simple example:
I want to perform the action User.delete() and my only parameter is the user_id. Here is how each type of API would handle such a request:
REST API:
http://api.myservice.com/user/123978
...along with this uri request the HTTP header would be set to DELETE
Query API:
http://api.myservice.com/user/delete/123978
or
http://api.myservice.com?action=user.delete&user_id=123978
etc.
Unfortunately, for a long time I considered an API available via HTTP requests to be a RESTful API. I always new that the basics of REST were centered around placing the intention of your request in the HTTP headers via PUT, GET, POST, DELETE, etc. But when I would see APIs like GoogleBase, AmazonSQS, Facebook API, etc. I just reused the term "REST API" to describe them because I'd never heard it explained in another way.
Today it became clear to me the difference as I came across the term "Query API". A query API doesn't try to convey intention using HTTP headers like a RESTful API does. A query API simply says "hey put all the information you need for this request in the request itself". Personally, I prefer query APIs. Lets look at a simple example:
I want to perform the action User.delete() and my only parameter is the user_id. Here is how each type of API would handle such a request:
REST API:
http://api.myservice.com/user/123978
...along with this uri request the HTTP header would be set to DELETE
Query API:
http://api.myservice.com/user/delete/123978
or
http://api.myservice.com?action=user.delete&user_id=123978
etc.
Subscribe to:
Posts (Atom)
