2021 was an interesting year. Another year of the pandemic. A year of uncertainty and shortages. I bid thee good riddance. On to 2022!
]]>
2021 was an interesting year. Another year of the pandemic. A year of uncertainty and shortages. I bid thee good riddance. On to 2022!
]]>My thoughts go more along the lines of “I need to build a spice rack, and I only have pieces of wood. I need to fasten them together and there are several ways to do this. I don’t really want to kill the horses and make glue, I don’t want to smelt iron for the nails/screws, what do i do? I go to my handy toolbox, which happens to have many tools which have been refined over the ages and then I pick the tool which will get the job done with the least effort. Sure there are more tools than I need, but at least I know I am not going to make a nail out of the wrong material and expose some structural weakness in my application of the tools”
]]>
A not-unruly queue
Recently, I have been doing some work on a pet project which is related to IoT. Part of the project requires a device, with a potentially unreliable connection to the server. The device sends messages regarding the state of certain variables, which are then processed by the server.
One of the first things I realized when I was testing, is that things went south fast if the connection broke between device and server. So I started on a quest to make it more robust. Mind you, this should not have been a quest, but I could not find the tools I needed. The most important tool for handling failed connections is a queue, which can act as a buffer for when the thing emptying the queue (the connection) stops.
There are MANY queues available for NodeJS, but after trying 4-5 of them, I could not find one which met all of my requirements. The requirements are:
After a few days screwing around with it, I finally have landed what I feel is a pretty robust queue for NodeJS. Since I am creative with my names, I opted to call it “robust-queue”. It is a package on NPM and open sourced on GitHub. Check it out here.
The queue makes use of the EventEmitters3 package, which improves the performance over the standard EventEmitter package. It also allows for pausing and resuming of the processing, which is important when it is being used a buffer for unreliable internet connections.
I have some additional enhancements such as modular persistence that I want to do to the queue over time, but for now it seems pretty robust ?
]]>
It has been quite awhile since I was publishing anything. I couldblame many things like the birth off my son, absurd hours being worked for my former employer, travel, etc. Those are excuses. The truth is, I actually HAVE been writing, just not publishing. I have many posts in semi-finished form. Over the next month, my goal is to finish them and publish them. You deserve better, I will be better. Maybe.
Back in May 2015, I quit my job at Tech Data. There were may reasons, but it came down to doing what is right by my family. I was running the number one strategic initiative for a fortune 500 company, and it really took its toll on me. Somehow, we ended up in arrangement where I would work 3 days a week or the next 4 months to help with the transition. This time was great. I was still being paid, working fewer hours, was able to see my wife and son more often, and really gave me time to figure out he next thing in life. Alas, the arrangement was not working out for either of us. So on September 10, I said my goodbyes and walked right into a new era.
During those partial weeks, I established two new ventures (well 3, but we are not talking about the stealthy third one yet). Pigott Consulting and Pythagoras.
Pigott Consulting is my individual consulting firm specializing in small businesses and startups with full IT service as well as strategic advisement in may areas. Think of it as a part-time CIO. You are interested in these types of services, reach out to me.
Pythagoras is a partnership I formed with a friend who has a stellar IT consulting background. We go after big projects with medium, large, and enterprise clients. Our advantage is that we only work with the rock stars of the tech world, which allows us to deliver superior products in shorter time. If you are looking for your project to be done on-time, on-plan, and on-budget, we would love to hear from you.
My experiences in setting up corporate entities, setting up my office, getting my professional tools setup, and learning new techniques should provide ample fodder for future blog posts.
]]>For several years now, I have had numerous assignment to write an electronic agreement system for one use case or another. After 4 rounds of it, I am seeing some trends in how things should be best organized. I am also seeing pitfalls where the whole thing could fall apart. Since the whole point of these things is to be a legally-enforceable agreement, terms and conditions, signature, or whatever the word flavor of the month is, we need to make sure it is bulletproof. Typically this is accomplished by leveraging a service like EchoSign.
In my typical challenge-everything way of thinking, I decided there must be a better way. Essentially you are paying quite a bit of money to EchoSign and when you boil it all down, you end up with a 3rd party who is vouching for the integrity of the agreement. This means, at the end of the day, either the custodian of the record cannot manipulate the agreement record without invalidating the record (my way), or the third party has a vested and audited interest in maintaining the integrity (EchoSign's way). So this got me thinking about the following question. How can I write an open-source, free solution which enables anybody to verify the validity of the information in question? Oh, and I need to make it happen in 2 days since I am under a deadline.
The solution requires a snapshot of the relevant pieces of information at a certain time be hashed and then that hash needs to be published to an open, independent, and reliable 3rd party. The answer to that question hit me like a ton of bricks. Bitcoin block chain! Bitcoin does a damn good job of ensuring the integrity of the BitCoin block chain, because without the integrity the currency would not be trusted and the double spending problem would rear its ugly head.
Now that I had my solution determined, I needed to figure out how to make it happen. After Googling a bit, I ran across this awesome sitehttp://www.originstamp.org/ which allows you to ensure time-stamped possessionof anything by hashing whatever you send (or you send the hash) and then it embeds the hash in the block-chain once per day. As an added bonus, it immediately tweets the hash as well, which means we are doubly publishing the fact that we had the given hash at a certain point in time. Since I am on a deadline, I decided this service will be much easier to make use of instead of writing my own integration with the block-chain. Naturally I will abstract this functionality so additional adapters can be written in the future.
Now that we have the third-party thing sorted out, lets take a look at how we need to setup our application to work with this. I am using PHP, MongoDB, and Symfony2 for this exercise currently as it is the technology stack we are working on. The same techniques should apply with any other language though.
First thing we need to make verifiable is the agreement itself. This represents the text and any rules associated with the agreement, as well as a name. This should never be updated, only replaced with a new version. So at the most simple terms, we have an agreement which has a date created, some text, a name, and a version. A version is specific to the name. IE. If the agreement is used when trading your first-born for a new TV, I could give the agreement the name “FIRST_BORN_FOR_TV”. The important part is that it does not change, and that it is not the same as other agreements you may be keeping track of. If you are a normalization Nazi, then you probably want the name to be a UUID. Now when some lawyer gets a hold of our agreement and invalidates it because we are inciting slavery, we need to update our agreement for all future customers. Perhaps we change the wording so it has the same net-effect, but now we are not owning a person, but merely being the recipient and director of all labor for the rest of the first-born's life. Now we create a new agreement using the same “FIRST_BORN_FOR_TV” and increment it to the next version. We create a SHA256 hash of the name, version, UTC timestamp, and the text of the agreement. Then this is stored along with the agreement. At the time of creation, we have also published the hash to Origin Stamp via their API. You can see my first test agreement published to the BitCoin block-chain and on twitter at the links below.
Looking at the hash, you say, “so what? This doesn't tell me anything.” You would be correct in that it is not much use other than being able to prove that the creator of the hash (me) was in possession of the hash by2015-04-05 02:22:45 UTC at the latest. This means I did not generate the hash later than that time, which means the data I stored can be verified that it did not change from that time. What this means is that a third party can take the data we stored as the agreement, run it through the same hash generator, and get the same hash. If anything changed, the same hash would not be created, and the information would be suspect.
In order to capture the event of somebody signing the agreement, we need to create a signature entity. This needs to have a reference to the agreement, the full name, the IP Address of the signor, the email address, and the date signed. We then hash all of this info (using the integrity hash from the agreement to represent the agreement) and we have a signature integrity hash. We then publish this.
One issue which may arise is any changes made to the system. Meaning, how do you deploy any changes to the hashing system (like capturing additional pieces of data). This is also solved through hashing. Conveniently we use GIT for our code repository, which has a unique hash for every commit. All we need to do is capture the git hash at the time of the signature, store it with the signature record, and add it to the hash. In this way, we know the code used, the data, and the point in time. This can all be verified by a third part who can get that point in time of the code, recreate the same hash steps, and recreate the same hash, thus proving that we captured the exact data at the time when the agreement was signed and not after the fact.
My wife has suggested we call this technique HashCash. Between the long explanation of BitCoin and Hashes, I think she tuned me out and this was her way of showing she was still listening.
TTFN
]]>Anywho, I originally set up her blog back in 2012 with a Hostmonster site. I have since been lazy and have not maintained it. So today, I finally go around to moving the site over to wordpress.com in order to let the good people at Automattic (the makers of Wordpress) deal with patching, scaling, and backups.
You would think with a service offering that they charge for, that they would make the path from their free software hosted on your own server to their hosted service a smooth one. I can tell you it is not. Some gotchas to watch out for.
We got the site moved over, it is much faster and cleaner now, so perhaps it was not all bad. Next step is to close down the pesky HostMonster account.
]]>If Celebrity Jeopardy has taught me anything its that there are unintended ways to interpret everything. While I do believe that “The Pen is Mightier”, I also have to chuckle everytime I see it as I cant help but think of “The Penis Mightier.” So now I have “Anode Tome” which would literally mean “big book about anodes”, which as appealing as it sounds is not what is attracting people to this site in droves.
What is attracting people to this site is an overwhelming desire see what I am doing in my ever-so-interesting life. So we arrive at, “An Ode To Me”, which is fitting for all my legions of fans…… Hmm perhaps this explains why I do not have legions of fans…..
Sarah has a lovely decor sign that say “Let it snow” next to our TV. I can’t help but always see “Le Tits Now”.
]]>The design is pretty simple. 5ft deep, 20ft wide, and made up of 12x12 concrete pavers over crushed paver base. I decided to use some pressure treated 2x4s as the sides. The list of materials is below.
The best way I found to do this is to put the surrounding edge pieces in first using the stakes and get them level. In my case, the ground is not real level, so I had to dig a few inches down on the one side and the other side is a few inches above the ground.
Next step is to dig out/fill in the interior of the frame. Again, in my case, things are not level so I ended up excavating from one area and putting it in the other.
After getting your area leveled out, go ahead and put the weed block down. I immediately poured a few bags of paver base on it around the sides so that the weed block stays in place.
Patio edges showing weed block and paver base.
After that it was a matter of pouring lots of paver base into the opening and getting it leveled off. Make sure to use a tamper to compact the base so it does not settle. Now that we have a level surface, start putting the pavers down.
Last step is to put some 2x4s around the sides to finish the edges. Check out the pictures below to see the details better.
I started doing some research on how I would make this work. One of the best ideas I have come across is using an IBC tote and cutting the top off to make both the fish tank as well as the growth bed. In case you do not know what an IBC tote is, I have included a picture below.
An IBC Tote. Sitting in the corner of my shop for far too long.
A great tutorial on how to do this is embedded below.
Once I decided this was the way to go, I started doing some more Googling to get additional ideas. One idea that I really like is on Instructables. Raspberry Pi controlled Aquaponics. Which really got my wheels turning. I decided it was time to actually start the project.
I found an guy on Craigslist who was willing to sell me a tote for about $100. In the process of picking up the tote, I backed up too far with my trailer and gouged my rear bumper.
This project is getting expensive.
Once I had the tote, I needed to figure out where I was going to put it. Originally I had thought about putting it near the carport, but decided against that as the area around the carport is fairly nicely landscaped and I did not want to create an eyesore. Upon doing some further thinking, I decided to put the system on the backside of my shop. There is plenty of space, lots of sun, it is hidden from view, and it is close to the shop (and internet, which I will get to later). Plus the wife approves, which is a plus.
Having decided on a location, I set out on the task of building a platform to hold the tanks and some soft of roof structure in the future. If you want to know more about the platform, check out my other post.
Lets get to the more entertaining parts. I want to make the system automated. Specifically I want the system to have the following parts controlled by or reported to a Raspberry PI.
In order to make the automation work, I knew there was going to be a good deal of reading and experimenting. I was not aware just how much would really be entailed. I will chronicle my experimentation and development in subsequent posts.
I decided to go ahead and buy all the parts I thought I would need for automation pieces. The aquaponics stuff is below.</p>
Other things you will need (I already had these).
For the details on how to connect everything together, see this post. The next post in this series will be installing the sensors in the tanks, and then starting the system.
]]>