Month: February 2017

This Blog skyliner does a good job talking about a need for software development to move from monolithic code to smaller changes which are pushed to production more frequently.  

It still seems no matter what methodology of  software cycle development lifecycle followed it includes some level of definition, development, QA, UAT, and Production Release.   Somewhere in the process there is a merge of multiple items into a release.   This still means your release to production could be monotholic. Even Google and Facebook which revolutionized the concept of Continous Integration (CI) and release fixes daily,  only release major updates once a week.    

Reading the blog left me with the  question is the future of CI, to release single items to production, validate over a defined period of time and push the next release?   This entire process would happen automatically based on a queue(FIFO) system.  

That would imply that the if you run code across a SaaS platform that platform would support a Facebook like update where code would be pushed and updated while the existing code continues to handle the requests and the users wouldn’t see discrepancies, some validation would happen, code would activate and a timer would start on the next release.

Is this really a reality?  

How does any switch get sold in the last 10 years which doesn’t implement at least a simplified spanning tree?   We had to implement a distributed spanning tree algorithm for OMSCS CS6250, two assignment ago which was a few hundred lines of code.    If a switch can see itself over a port, can’t it just disable both ports?    This would prevent users causing issues, unproductivity and a nightmare of network troubleshooting.  

That code should exist in the $69 desktop switch and up, no excuses not to add a few hundred lines of code.   

Google production environment has a Borg, Chubby, Stubby and Blobstore.   This is covered in a new O’Reily Book on Site Reliablity which can be read online.

No clue why Tuples in Python are immutable.   It seems to me that this is a flaw in the language.   I’m no expert on underlying programming language architecture.    But it seems to me that if I want a

myTuple = {('NAMED1':variable1,
            'NAMED2':variable2,
            'NAMED3':variable3)}

Where there is some interrelation between variable1, variable2 and variable3. If I subsequently what to set NAMED3 to new variable4. There is no way to do this.

Wouldn’t it be nice if one could do?

  
myTuple['NAMED3'] = variable4 

So now I’d have:

myTuple = {('NAMED1':variable1,
            'NAMED2':variable2,
            'NAMED3':variable4)}

This fails because of Tuples immutability.

One way to overcome this is create a new Tuple and then delete the existing Tuple.    This becomes very interesting when I have  list of Tuples were you make a new tuple add it to the list and delete the existing Tuple.

Seems like a lot of hassle for a language which is suppose to be very programmer friendly.