Posted by Seon
on July 27, 2008
I think at one point in time I was routinely drinking close to 1000mgs of caffeine. I remember drinking multiple grande lattes a day (2 shots in a grande vs 3 shots in a venti).
Starbucks Venti Twenty ounces = 415 milligrams caffeine
Based on some of the information in these articles, I believe a majority of my sleep problems are related to my caffeine intake. I am going to try cutting out caffeine intake from Starbucks drinks for a month.
Polyphasic Sleep
I ran across a blog chronicling one person’s 5+ month experiment with polyphasic sleep. I had originally been Googling for information about sleep disorders since I’ve been unable to get a good night’s rest for a longtime (years?) now.
Polyphasic sleep involves taking multiple short sleep periods throughout the day instead of getting all your sleep in one long chunk. A popular form of polyphasic sleep, the Uberman sleep schedule, suggests that you sleep 20-30 minutes six times per day, with equally spaced naps every 4 hours around the clock. This means you’re only sleeping 2-3 hours per day.
One of the upsides is the extra awake time you gain for activities. The major downside is that you will be on a fixed sleep schedule that likely conflicts with the rest of your friends and family. It’s a very interesting set of blog entries to read, and provides a lot of food for thought. I think I’ll stick to improving my monophasic sleep for now.
Posted by Seon
on July 10, 2008
This is probably old news, but I still get excited thinking about all the interesting solutions that are possible now using Mule and Gigaspaces for SOA problems requiring low latency and highly scalable architectures.
Gigaspaces released 6.5 with API integration with Mule 2.0 … this is just plain awesome. You can use Gigaspaces as the transport (e.g. in place of JMS) and quickly get a SBA up and running utilizing the same concepts I used at RHG when we were servicing B2B problems. You also get the advantage of the clustering ability and fault tolerance that comes with Gigaspaces – which is just pure sex – not to mention all the other great features that come with this advanced Javaspaces implementation (i.e. management tools, monitoring tools, data partitioning, performance features like batching).
Gigaspaces would have made a fantastic backend transport and shared data grid in place of ActiveMQ JMS, but at the time it wasn’t as fully integrated with Mule. We would have been able to solve alot of the high availability and clustering concerns regarding single points of failure with the messaging database and JMS brokers. I never felt comfortable with ActiveMQ’s clustering and fail-over features. Configuration seemed a bit fussy and it doesn’t seem to be as easy to scale out as a Gigaspace cluster.
Posted by Seon
on July 09, 2008
Google’s awesome, they release some nifty software to the open source community. Here is the link to Google’s Protocol Buffer and more details are available on Google’s Open Source Blog
From what I can tell, it’s a solid format that can replace XML in most scenarios. It’s not as easily human-readable as XML, but then again from experience not many humans are actively reading the XML anyways. The proto format reminds me of a json structure, minus the curly brackets. Also, from skimming the proto java documentation there isn’t support for primitive arrays (at least for java). You should be using List containers instead along with the proto “repeated” scalar.
They include code for data binding source .proto files to C++, Java and Python. This makes it easier to adopt in your next project. I think this is a good data format for internal use, but you’ll probably still have to deal with XML/SOAP and other RPC formats (JSON, etc) on your external interfaces. This would require transforming the internal data format (.proto) into the external format. There is also stub generating code for producing server interfaces that you can drop into your native rpc server implementations. This is pretty cool also.
Hmmm, I see some useful Mule and Camel transformers that could be made to take advantage of this new format. And possibly service adaptors for Mule and Camel too.
