Networking Week 5 - Hop scotch to India

This week was about the network layer which meant hopping around the Internet watching where things go one hop at a time. Videos and reading showed what goes on inside routers as packets move from one node to the next to accomplish a goal. Hands on work with traceroute was interesting because it showed information about each node in the network as information went from here to India as an example.  

Something I thought was interesting was how badly the first traceroute I ran to india failed. Then changing to doing a different type of traceroute caused things to appear nicely. It seems like the default should be the one that works more? That's OK though it worked out in the end and I got to see what kind of delays were between here and India. Everything was going nicely until after my packets left Los Angeles. I suppose that is why I don't see many people from India in the games I play! They would get allocated to servers closer to their homes of course.

Networking Week 3 - Don't miss the transport

This week was all about the transport layer.

UDP and TCP protocols live on the transport layer. If you are running a game and need to send player information updates between the client and server as fast as possible you're going to use UDP. TCP on the other hand is more reliable and bounces back and forth between two hosts to ensure the data is sent properly. So this layer is what you can use to build higher level protocols for your applications.

I haven't done a lot of programming at this layer so I enjoyed the labs this week going more in depth examining packets used for DNS. It is interesting to see how data moves through the transport layer to implement these higher level protocols. 

Networking Week 2 - What's that protocol?

In this week we covered a variety of fundamental application protocols. Each protocol showed an example of how you can use networking to accomplish different goals. HTTP as it compared to FTP shows the use of multiple ports versus a single port during an applications life cycle. Another difference that came up was using a p2p network topology compared to a client-server relationship. Using that kind of organization can let you increase survivability with off grid mesh networks which interests me. Also I don't like moving information through unnecessary nodes.

One of my favorite p2p products is gotenna. It just seems like a great idea for people to have their own cell phone base stations that create a network like that.

goTenna (goTenna Inc.) is a Brooklyn, New York-based startup that designs and develops technologies for off-grid and decentralized communications. goTenna devices pair with smartphones and, through intelligent mobile ad hoc networking protocols, enable users to send texts and share locations on a peer-to-peer basis, foregoing the need for centralized communications infrastructure of any kind.[1] - wikipedia

I don't have one of these products, but they do seem like an interesting way to augment peoples cell phone capabilities.

As for the networking assignments this week they helped continue the process of dividing the path information takes from one place to the next into visible pieces. I really like to be able to see things physically so packaging up packets and moving them through different layers is attractive to me. It will be nice to have a very solid view of information moving across space at different levels of abstraction eventually.

Networking Week 1 - What the ARP

This week I gained a better understanding of how packets are moved across the network and appear on each devices network adapter. The most interesting part for me was watching our Roku's keep sending ARP requests on the network. It's nice to know that regardless of changes to the network our Roku's will work hard to find their way to the internet and the netflix servers. The videos, reading, and exercises also helped to detach network protocols from networking hardware for me. Around my desk I've got all different kinds of radios and networking devices that use wires, 915mhz, and 2.4ghz for Zigbee, Lora, Wifi, CAN, etc so it is important for me to understand the different layers involved in networks.

As someone who took half this class before my expectations were pretty clear for content coverage. This does seem like an area you can play around with for a while and keep learning new things so I was not disappointed by watching the same videos and absorbing new information from them. There were unexpected aspects regarding the format for homework submission but I liked those changes. Having everything use the quiz submission form seems like a good way to keep things organized within the CMS instead of having us upload files with all questions answered.

Software Engineering Week 8 - The end

Course Summary

This course was a solid stream of software engineering concepts and applied work. There are two major takeaways for me:

1) People matter, a lot.
A theme that our instructor worked to get across was that people trump process. I am personally attached to the agile process because I do not know what it is like to work for people with high levels of planning. My career has been spent in small startup companies and generally chaotic environments where we design and deploy as quickly as possible. So that experience has probably misled me to believe that the process trumps the people. Generally I have been lucky to work with good people though. If I hadn't had such great people to work with then the process wouldn't have made things better.

In this class I was lucky to be assigned to a friendly and positive team with a good outlook. They communicated with each other and were not quick to get offended. So we could propose changes to the design, implement features, and work together without a lot of friction. This class was short and so was the team project but that only reinforces the point that people matter, a lot. With the wrong people this could have been a very negative experience due to the opportunity for stress presented by the timelines involved.

On the other end, the instructor for this course is highly focused on individual development. That aligns with my personal interests. I don't actually care what grade I get in any class, or if I pass, although that is a bit of a hassle. There isn't an end to learning for me and I could learn a lot if I had to retake this course. The problem for me would be taking a course with the wrong instructor and classmates. After all, people trump process.

2) Time spent on design is time saved programming
I have never been a heavily design oriented person. Generally I hack my way to success and figure out what needs to be done as I go along. This process presents a problem though: to scale up and delegate tasks to other team members I need to focus on learning the skills needed to share design ideas. UML for example is a great way to create a variety of diagrams that can convey your vision before work begins on a project. As work continues you can update these diagrams so the team has a shared vision. Without enhancing my skills in this area I will be limited in the complexity of projects I can engage in.  Software design is a core area for me to work on long after the course is over.

Software Engineering Week 7 - Getting Organized

Week's notes

This week was mostly about moving along on the final exam. I broke that up into a few nights to have time to think about things and go through the problems. It took a good amount of time to make things nice and there was a lot I didn't know before taking the test. Java interfaces for example was something I hadn't looked at much before. Interfaces provide a nice way to follow a pattern for your classes and the best article I found was on tutorials point of course. They seem to have the best info out there. The reason I had to look up interfaces was because of a question about using a publisher/subscriber pattern. The big thing I know about pub/sub is MQTT, a protocol for publishing and subscribing messages. 

Aside from the test I need to get back on our team project. We stopped before doing our first refactor. Without moving the gamestate out of the main game loop we can't call ourselves a view/model/controller based program. So there is some more work to be done on that. I still haven't figured out JPA and how to get Java to work with MySQL though. That is my big concern for reaching assignment criteria, but more importantly for doing something interesting. Getting a good grade is less important than learning how to do interesting things. 

Software Engineering Week 6 - Getting Organized

Weeks Notes

This week was about getting our project up and running, deployed online, and managed with pivotal tracker. One team member took a clear lead in developing the base software for our game. I scoped out what was going on and updated pivotal to see where we could go next. It was a fun week for sure but a bit stressful. My concentration has been on the team project and not really on gannt charts which was another topic for the week.

The content about gannt charts makes me happy to have friends who enjoy project management. I hope to continue to work with people like that and avoid this kind of organization as much as possible. In contrast this pivotal tracker program for Agile projects is really fun. It is nice to set goals for the week and be able to comment on them or move them around with ease. That kind of project management is no problem for me.

Using Pivotal Tracker and figuring out how to compile, debug, and upload the style of Java applications that this class uses has us at a nice start. Things are almost over though so that isn't great. I would like this class to be twice as long and have more fun with our application but that isn't reasonable because of the way this program is setup. The alternative of attending classes in person isn't an option for me either though due to work. So I think the 2nd best, and most expensive option is to just take classes like this a few times so I produce usable products.

Looking ahead

I still haven't been able to get a local JPA application working with MySQL. So that is the big problem for the next week. If my team gets it working on the server that is fine for the project but I need to be able to duplicate anything locally. By being able to run, debug, and modify the program locally I can do a proper code review and provide useful feedback for where our software can head during the next iteration. We also need to do a refactor to get our software away from everything running in the main Java applet. It would be ideal to have the applet handle the requests but have game objects that keep track of game state and let us have a game loop off to the side.