Pull Request, NSQ, rUDP, Engineering, ESB, ICT Standards, SSH, Kubernetes, Startup business

Post date: Jan 31, 2015 5:38:53 PM

A better pull request - Excellent visual & code samples about issues encountered when merging Git branches.
Studied and tried Boxstarter and Chocolatey with virtual test servers. - Could be components to use in future, but more complete configuration management system (CM) is needed.
One Man's Mission to Build a Galactic Internet - OneWeb aka WorldVu - https://en.wikipedia.org/wiki/WorldVu_satellite_constellation - I think it's going to be rocky road. Similar projects in history have always failed. But let's hope for the best. Excellent article.
Implemented efficient off-line backup solution which saves over 90% in costs compared to earlier solutions being used. As bonus it's also faster and consumes less server resources. System is also being monitored constantly and naturally delivers automated alerts if everything isn't working smoothy.
Investigated real time fail over, manual fail over (hot spare replication) and off-line spare solutions. Current solutions focus on low cost and reliability. Which trades off recovery time. So data isn't getting lost, but putting system after total fail back online might take a time, especially if multiple systems fail simultaneously.
Quickly played with NSQ - " NSQ is a realtime distributed messaging platform designed to operate at scale, handling billions of messages per day. " - No need for this currently.
Watering hole attacks towards Android developers. - Dangers of networked software suppliers. Lower security environments can be used as proxy to high security environments. As well as even to fully isolated environments, because updates might be carried using USB memory sticks or transferred over VPN to highly secure environments, which of course immediately become much less secure environments.
Tested OpenBazaar rUDP feature branch, there seems to be a few things to fine tune before it's actually working. Basically it's working but throughput is bad and mediator mode where intermediator is used to connect two peers which both are behind NAT still require work. We tested multiple different work configurations with different NAT and network setups. But it's nice to see progress being made.
Had a way too long discussion about what's "private server / private network" and what's "public network / service / public server" and so on. It seems that a few developers are really badly confused about these things.
Thought about a few new Tor related services which would be interesting to build as hobby.
Read article about remote engineering being hard. - Yet I have to say that the article didn't provide any new information. Lack of information, communication issues and all of that stuff is very familiar to me. There's huge difference if everybody doing the project are experienced and know what they're doing. If there are guys who aren't competent, it will ruin everything. Because all that what's NOT being said is really important too. There are so many things that are assumed. Do thing X, of course means that you'll do about 10 other things which are dependencies for X happening. In open source development teams this is also really easy to notice. Assign port X for application. Well, of course that means that if you're behind NAT and stuff like that you also configure it. It doesn't need to be mentioned, it should be obvious.
I often encounter situations where I'm being called to quickly find out why integration X isn't working "at times". List of possible reasons is endless. As well as often that's all the information I'm getting. I don't know anything about the network, configurations, devices, interfaces, where those are hosted, servers, server resources, configuration and so on. Point is that just well, it's not working, fix it. Solving this remotely without adequate information can be really hard. Especially when integrations are chained, client device talks over, to server, which then calls system X using another protocol and so on. Of course the report doesn't give any indication what failed, it just let's you know it failed. Sometimes the issues aren't even related to the problem. Like ticket validation integration ins't working. And you'll find out after investigation that there's some butter or snot on the lens of the barcode reader used for reading the code being validated. Cable is broken, usb connector is bad, usb drivers are bad for the mother board and list goes on. - Fun, so much fun, everytime.
Lightly checked out Mule ESB
Checked out ICT Standard Forum
Attended training about Backup as a Service (BaaS) which is based on IBM Tivoli Storage Manager (TSN). Service is provided by Enfo.
New P2P programs probably got following issues. TCP problems with NAT if port forwarding isn't done. If UDP is used the STUN & TURN can be used. But next problem is that because UDP is used, now all the things which have been take care by TCP earlier have to be reimplemented. Flow control, retransmissions, timeout(s), transfer windows and stuff like that. It all is seemingly simple, but when you start to really implement it, you'll find that you're going to have bad and very bad time. If that's not bad enough, next you need to start considering different abuse cases, forged addresses, potential UDP amplification attacks. When data structures are stored in memory, are those properly limited or not? If not, it's probably possible to flood service with packets which cause local resourse consumption attack, system runs out of memory and potentially other resources. After that when DHT is being used, there are different kind of DHT data flooding attacks, so you can fill tables with junk, get system to run even out of disk space or make it just generally slow and so on. So list goes on and it's going to be hard, before it's good, really hard. Doing naive implementations is fun, making something which really works excellently isn't fun, it's going to be tough time.
Checked out Web login using SSH. - Which is yet another solution. There are plenty of solutions, which aren't particularly great. Just like I talked with someone in playment industry about Apple Pay. I said that it's basically so simple. User can receive a payment request token signed by the payment handler telling what is being paid and where and then user just confirms the amount and signs the response. Secure PKI payments is simple. Problem is everything else. Legacy tech, banks, etc. Technically it's not complex at all. Just like the OpenBazaar uses triple signing for contracts to make it clear who's dealing with that and that the transaction has been successfully completed. - Like all that discussion about credit card payment tokenization.
Spent a lot of time going through different markets, ETFs and stocks as well as reading econony news and reading a few latest issues of The Economist.
Everything you wanted to know about Kubernetes
Refreshed my memory about national official radio communication protocol. Com check, call signs (structured & standard), communication protocol, locations coordinates, names, alphabets, use short communication, basic communication pattern check list. We went through this in the military but it has been a since I've been there. Know your equipment and it's features well. Directional antennas and stuff like that.
Revisited (once again) some basic business topics, business idea, understanding market, prototypes, business model, business structure, business plan, marketing strategy and market analysis, business operations, roganizationla strcture and team management, cash flow analysis, performance measurement, risk analysis, financing startup, social media, intellectual property, human resources, branding, entrepreneuership, leadership, taxation, tax optimizaiton and tax heavens. Many Finnish companies have been talking about moving to Estonia or Sweden, Finland is not the land of opportunity right now.
Had a few beers with a good old friend, who's considering starting an interesting startup in Finland. But that's all pure speculation so far. It could be successful and he got the (technical) skills needed to pull it off.