Capstone Week 7 - The beginning of the project

At this point in the class there are no updates to make to the report or other deliverables. I think I am going to pass. That would be great. After this class I have three more to take at a community college online. They should not be very much trouble.

With this class wrapping up it is really the beginning of my colorimeter project. There is a lot of work to do to continue iterating and have a core device that is useful to more people. Right now it is only really useful to engineers that want to take the pieces. 

Overall I feel pretty good about this Computer Science program and that I balanced meeting the criteria with doing something I enjoy. I hope to continue my project and deploy it to more users while using it for my own farming systems.

Capstone Week 6 - Sometimes Things Work Out

The official topic for this weeks learning journal is about the ETS test. I did not take this test. To be honest when I got invited to take this test I thought it was on a hidden camera show or being tested because of the software you are required to install to take the test. In order to have a proctor tell if you are cheating you need to give them control over your computer to see what you are doing, what programs are running, etc. That makes sense if you are using a virtual machine and locking the proctor in a small container or are using a disposable computer that has no personal information or access to your home network. I did not have to do either of these and did not have to take the test, so that was really nice and got rid of a lot of stress. In the end I would not have installed this software and would have worked hard to get a low passing grade instead if it was a big problem.

Instead for this week I focused on assembling, debugging, and trying out my circuit boards for the colorimeter. That involved a trip to "Smart and Final" to get a hot plate and cooking the circuit boards like pancakes. The tools I have at home aren't great for this, so I did have some problems. Those problems put me in a great position to select and buy equipment for companies that need to move very quickly. With this personal experience I can continue to push for reflow ovens, high quality soldering tools, high quality solder paste, etc without any doubt.

In the end I had a short circuit on my light board which caused one of the data lines and the light output lines to short to 3.3V. This prevented communication with the color chip. Fixing this problem was nice though because it showed me that if you follow the data sheets for sensors and other microchips then sometimes things work out great. Read the fine print, do a good job, and things just work!

Capstone Week 5 - Presenting Prints Ahoy!

This weeks capstone material presented good points about presenting. It is easy to try to make content super impressive and technical. That doesn't do the presenter a lot of good though. A presentation should be understandable. For me this is important because there will be people outside of my target audience that can help with a project. There are large gaps in my knowledge relating to business and profitability. So if I am giving a presentation about a device that I am working on it would be good to also make it understandable by people with a different field of interests.

Also discussed was making a presentation memorable and emotional. When I give a presentation I try to focus on having very little that needs to be remembered other than a few words that link the structure together. Making a presentation connect emotionally is about honesty.

Outside the reading this week was about designing and printing parts. Although on accident, there was a good lesson in material saving this week. By stopping my print accidently after the first key features were built I was able to make a few small alignment and fit changes. In the example image below the test tube is loose in the holder, so a tighter section was added to the top. The light sensor board on the right was offset slightly by around 1.5mm. So that component was shifted as well. This kind of partial print technique would be good for many applications, including making a close fit around an odd shape.  

 

Cutaway view of print for test fit check of sensor board, light board, and test tube.

Capstone Week 4 - Open Source Hardware Workflow

This week had a bunch of good reading about interview questions, getting your foot in the door at a new job, etc. I enjoyed that reading but didn't really get much out of it. I am starting a new job soon, if I lost that job I have a few good backup options with great people. Being in between jobs this week does mean one thing: no access to SolidWorks. So what should I do? Well I have been thinking this day would come, and don't really like expensive software or "cloud CAD" like fusion 360. These options are good for high end design and manufacturing. A lot of what I have made over the years is pretty simple though. That is where FreeCAD comes in.

FreeCAD is the mechanical counter part to KiCAD (which is for circuit board design). They are made by different people, but combine you can design electrical and mechanical components. I have messed around with FreeCAD a little bit but this was my first week really using it to try to design something. It went OK so far, but I will really commit to using FreeCAD for all of my open source projects moving forward. The overall open source software work flow for my projects will include all three of the following:

KiCAD - Circuit Boards

FreeCAD - Mechanical Design

Cura - 3d printing, I will use the lulzbot edition, which combines an open source 3d printer with open source software. 

EMC2 - CNC machine control, milling metal and plastics

Each of these programs is free and has their source code available online. The more people that use this kind of workflow the more money we can all save and the more we can collaborate. If you are going to sink a ton of time into a project, why not give it a long life by having it be open source? That seems to be the way to go to me. 

Capstone Week 3 - Integration time, averaging, and repeatability

This weeks learning came in form of a series of graphs as the embedded and control panel software were modified simultaneously. This path began with  erratic values given from a high intensity flashing light source with low sensor integration time.

 

Poor target illumination(intense short flash) and sensor timing yield erratic values with wide range. Low integration time also gave a narrow range of values from maximum to minimum light intensities. Increasing the integration time of the light sensors gave a wider value range and higher resolution.

Illuminating the target before sensing, averaging multiple samples, and receiving stable values from the 18 light channels.

 

 Running two rounds of calibration using six sample concentrations with stable and repeatable values 

 Final result with one invalid value, possible swap or mixing error. 

 

Modifying the NodeRed display panel software and embedded software simultaneously appears to be a good way to quickly experiment with a device and close in on a desired result. I would recommend this route to others doing similar development efforts. 

Capstone Week 2 - project planning as an explorer with a funny hat on a 3d surface

    This week came with an important decision to make. The sensor I had selected was not performing at the level that I would like to see for this kind of device. So the sensor was immediately abandoned and a new sensor was connected to take its place. One quarter of the way through a project it is critical to have the basic functionality established so that a full evaluation can take place. If that means using cardboard and hot glue with some development kits then that can work. The important part is to be able to have full project visibility by knowing the components and how data travels between them as a connected graph.
   Another aspect of this weeks development cycle was prototyping material selection. I choose to use hot glue and cardboard with scissors. At first that seemed a little odd to me, selecting from processes like laser cutting and 3d printing. In reality this does exactly what I need: hold a test tube, light source, and light sensor in a repeatable position. It also has the benefit of reducing the impact of the high brightness LED flash on people around the device.
   By pivoting as necessary and not wasting effort and material with unnecessary prototypes this project can hit it's objectives.
   This is the strategy I try to follow for any project: There are hills and valleys in the problem space for any new development. If you can't get up on top of the hills to see into the valleys you're not sure what you will find. Climbing a few of the key mountains early on, even imperfectly, gives you visibility and functionality. Each of the valleys you see could take years to fully explore. It is critical not to get trapped in these valleys though. So get up on the hills, build graphs showing their relations, and map the surface to project completion.

Capstone Week 1 - prototyping

Nitrate solutions of varying concentration

   This week was all about MQTT, Mosquitto, NodeRed, and the ESP8266. At the start of a new project it is important to hit all areas and find your risk items. For my colorimeter capstone that meant setting up the server, building and programming an embedded device, running first dashboard trials and taking real measurements.The results of each step in this first week prototyping process will determine the direction of the project for the remainder of the course. 

   The first risk item identified was the lighting source. Initially the LED was run off a 9V battery and resistor but an unstable spiking and then dropping off light level was measured. To accommodate this spike and drop an AMLD-6070Z LED power supply was added. This device was configured to have a constant but adjustable current output to stabilize the lighting source.

NodeRed flow for receiving colorimeter data and estimating nitrate

Dashboard for basic nitrate display & debug

  With only three data points and a preliminary sensor device the results are not completely solid. Averaging of 20 samples was used to remove noise in the sensor data. This will be combined with more data points on the calibration curve. No housing has been built, so there are other lighting consistency concerns to address moving forward. These concerns revolve around the repeatability of the light path going through the test tubes, and exterior lighting. Adding a housing which gives repeatable positioning between the light source, sample, and detector should also help improve these results. In addition it will block ambient light which will remove another variable from the lighting equation. 

 

First known sample results

    Overall the strategy for this project has been to hit the key targets, then improve each of those targets as time allows. That strategy will result in a functioning device with a full scope of improvements and risk items for device success. Moving across targets like this on a project is a critical skill to have in a career within technology development. Collecting user feedback involves rapid iteration and review. If a long time passes between the availability of functional software then the user can't provide feedback. By operating my projects in this fashion I can continually integrate user feedback by showing demonstration sections that operate.

Networing Week 6 - A well directed graph

I'd like to start by saying that I really like graphs. So this week's focus on routing algorithms was a lot of fun. Some of the parts got a little bit crazy as far as the different styles of routing algorithms presented in different forms. There was a variety of videos provided in different styles that made the information approachable though. This is really the ideal way for me to learn and I spend most of my free time time that isn't spent gardening studying videos to learn other topics.

There was also an interesting change with one of the assignments where it looked like you could take it as many times as you'd like to get more points. I didn't do that though. What I did do was go back and fix my obvious mistakes like selecting 4 bytes when I meant 2. So the option to fix dumb errors was nice. Those kinds of simple mistakes can leave you with a 60% instead of 80% so I appreciate that option.

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.

Software Engineering Week 5 - People Solutions

Week's notes

The focus for this week was on interacting with others and the importance of reviewing each others code. Based on the reading it seems like the agile process supports better code review than waterfall. The ideal code review seems to be around 60 minutes long for around 3-400 lines. Weekly short code reviews allow people to find errors without getting burnt out. If your development cycle is based around 1 week intervals with review and refactoring going on then there probably aren't going to be huge new chunks of code that you haven't reviewed any of before. That seems ideal for maintaining code quality. 

Aside from code review there were tips on how not to offend people and make things go smoothly. This doesn't sound like as much of an issue to me because these things work themselves out. If somebody is really terrible with people then they probably have some kind of social disorder. On the other hand they could just be rude. Ideally they have some kind of social disorder which you can figure out to become great friends with them. If the problem is that they are just rude then you won't end up working with them. Recruiting and management should factor those people out before they cause too much trouble. So advice on working with difficult people isn't really that great unless you're trying to be a salesman. The best advice for "working with difficult people" is to avoid organizations with poor management and recruiting so that you don't have a terrible day. Otherwise you are wasting your time and health.

In the background the homework continued learning about interesting Java technologies with applications in certain commercial fields. I'm still trying to get all of this going. MySQL is setup and I can use the workbench that came with it to load up a basic table. The problem I am running in to is related to running the JPA program that actually connects to the database running on my local machine. It's also still a bit tricky keeping track of how all the different Java things link together, what they need to run, how they all run, etc. The technologies seem useful though and established as a standard way to build applications. It does seem like a good deal of repetition and study would be needed to utilize the whole Java webapp route. 

  

Looking forward

Moving ahead we are ramping up on our group project. A basic repository is setup and game frame work is being built. The big trick here seems to be getting going. It is important to get a working base going that we can grow off of. Without that base then you could end up in a bit of a traffic jam having everybody trying to do the same thing. So I look forward to us branching out this week and then selecting and hitting targets with our project management software. 

Software Engineering Week 4 - Don't get hacked and do your homework

Week's notes

This week was pretty good. It feels like it is a bit slow for me to absorb the information but I enjoy the current course material. I am trying to learn a lot of new things in different areas at once so that can make my learning velocity feel like it isn't good enough. This week settled some problems for me by focusing on being device independent so I can do my work anywhere. I can have a different device for software development, design and documentation, and use other devices for course assignments like this. 

 As far as learning for this week, after trying out a few different programs for making UML diagrams my favorite is a google docs plugin called draw.io diagrams. The important thing for me is that I can access my files from any computer running windows, Linux, or chrome OS. That way I can spend more time on my course work. When things are locked to a single platform or require software installed on every device then that puts a wrench in things for me. 

Aside from process improvement there was some good reading this week comparing hacks of Sony and Target. The important thing for me from these articles is that inside the designer facade of a companies brand there are just people working at their computers. Every company isn't filled with super hackers designing their systems. Sometimes people just want to buy some software from Microsoft and get things up and running. Then they end up getting their systems broken into and lots of account information leaked. 

I don't fall into the category of people who say this is inevitable. If somebody is really motivated they can hack any system right? If the system is well designed then it gets harder though. Exploiting software and protecting against unwanted software use it isn't an area I know much about though. The important thing for me to keep in mind is what I don't know with regard to security.  By doing that I can work to avoid setting up critical systems without consulting experts. Also by utilizing known libraries when possible instead of getting creative with security schemes I think I can help to avoid introducing new opportunities hackers. 

Upcoming work

The exciting part for this week is ramping up our group project. Thanks to the selection of the Agile process for this project we can really make something fun. By having the project open ended and with a short weekly cycle of design/develop/deploy we can make something interesting without stressing out too much. 

Software Engineering Week 3 - UML could work out

Week's notes

The focus for this week was running into problems with a bunch of Java technologies to prepare for our upcoming group project. If we ran into these basic problems in week 5 then we would be out of luck. Instead we should be able to make a deliverable over several iterations. This week by making a hangman game with servlets and jsp files we demonstrated the key pieces needed to build a web app as a team. Key problems included loading two resources types from the server to display in dynamic pages and saving different game states per user. User input was also included but that was in earlier homework so not super critical.

UML  - A bunch of different types of diagrams with one language

At first glance it might seem like UML is going to be some niche way of making software diagrams, like using google drawings or custom drawing apps. Before you know it maybe you're up and running trying to make diagrams with UML to solve problems without knowing what's really up. That's how I felt until seeing that UML could be really useful. The surprising part to me is that there are so many diagram types that are all written in this language. Until today looking at these diagrams I wasn't sure what was going on and a little frustrated when new diagrams that claimed to be UML looked so different from each other. I think this is due to a resistance to be sold on a new keyword or language until it settles in. 

Design Patterns - they have some names

Remembering the names of design patterns seems pretty tricky. My interest is in the shapes that you see in software and matching the patterns to have a clean flow. So I look forward to studying more of these shapes and looking at sample design patterns. 

Software Engineering Week 2 - Test it all

This week I had some problems that threw me off a bit. So I didn't submit anything really. I did learn a lot from the reading and videos though. From those I can tell that big waterfall style software projects are not really my interest. Listing out how everything is going to work seems like a job for a different personality type than mine. What I like to do is lay out close targets for what can be done and then figure out where to go from there.

An example would be writing a piece of software to test an electronic device. Instead of getting all worked up planning the test software my first order of business is going to be making sure that I can control the instruments needed to interact with the device. This would result in needing to get GPIB and ethernet control of the devices working. With that doorway open I'd move ahead and lay out a few more close targets to hit until I reached my goal.

I can see the case for using things like UML diagrams though. Instead of using them in a waterfall process it would be nice to share them as google diagrams and update them as the project goes on. We will do that in week 4 I believe as we ramp up our team project. Normally I just try to keep these kinds of diagrams in my head as I work on a software project. Laying them out on paper seems like a good way to keep everybody on the same page though as we collaborate in a group format.

The emphasis on test was also interesting this week since I have worked in manufacturing test for a while. Having a test for just about every single piece of your program really seems to make sense but I haven't worked like that before. It reminds me of working on a poorly documented electrical cabinet for a test system. When I was first deployed to work on this large cabinet I wasn't sure where to start. Then someone told me "just trace every wire" and I thought they were joking. Sure enough, I went ahead and spent weeks tracing every wire to every electrical component and documenting it on a new schematic. This seems a bit like the test route where we should really have tests written for all of our code. At first my reaction is "really, every piece??" but it makes sense. The availability of automated test suites that can run through your tests makes it appear that this would actually pay a good dividend in the end. So long term I would like to follow along with this and figure out what the proper automated test route is for a given software development environment, Java or otherwise.

So this week I lagged due to some personal problems and I might fail but that's OK with me. The important thing is to just keep at it and learning new skills. Every repeated class gives me even more time spent reading and solving problems. I don't mind being a bit slow or scattered as far as my thinking goes as long as I can build interesting things.

Software Engineering Week 1 - Off to a good start

Week 1 - Off to a good start

There's lots of different people in the world so starting a new class is always interesting. The great thing about this class is that the way it is being run makes sense. There's no weird stuff, no tricks, things are just laid out in a way that looks well designed for student skill growth. What are the key attributes that appear so far which lead me to believe this?

1) Course content available early - If you are disorganized like me and only looking to focus on critical tasks as they pop up it is important to have as much information as possible. A friend once told me to ask the question "what happens if you do nothing?" as a metric for task priority assignment in a resource constrained environment. With more information available I can find key targets that can be hit early to prevent stress if

2) Consistent forum posts leading to e-mail updates on my phone for core assignment road blocks - In a class like this there are going to be generic problems that everybody runs in to. The instructor and TA in this class seem well aligned with the tools at hand and quickly respond to growing problems early enough during the assignment week for resolution.

3) Open ended assignments - This is a critical attribute that seems to appear in well run art classes. By leaving assignments open ended there is room for people to focus on the areas of a problem that are inspiring to them. As an example in an English class of mine there was extra credit for making a video about a writing topic. So I went ahead and produced a short cartoon on my computer, loaded it on to a VHS taps, and played it in class. The other students weren't sure what to make of my cartoon with a dinosaur eating people but the skill growth was there for sure. Similarly in a software class like this there is room to throw in a cutout of a dinosaur or anything that makes you happy and doesn't mess up your agile schedule.

There are still plenty of ways to mess this up for sure. It won't be because of poor course structure though. Personally I look forward to seeing what cool projects people create within this framework over the coming weeks.