You’re (still) a data scientist.
For Modeling & Simulation (CPSC 420), I had to model the spread of a forest fire from a lightning strike. Here are the real specs:
- It will feature a 2-dimensional cellular automaton of dimensions 50×50.
- When the simulation begins, the far right edge of the grid will be populated with houses. Each far-right-edge-square should have a 40% chance of containing a house, and a 60% chance of being empty.
- When the simulation begins, the remainder of the grid (i.e., all squares except those at the far right) will be filled with trees at a rate of FOREST_DENSITY. This parameter will be a number between 0 and 1, giving the (independent) probability of each square on the grid (not including the far-right edge) containing a tree. Start with a .7 value for this parameter. Other squares will be empty.
- Assume that the forest boundaries are a barren wilderness; i.e. all “squares” beyond the edges are empty squares.
- At each time step of the simulation, there will be a PROB_LIGHTNING probability of a lightning strike somewhere in the left-half of the grid. Initially set your PROB_LIGHTNING to .1. When lightning strikes, choose a random square on the left half of the grid. If it is an empty square, the lightning does nothing (except make a bright flash and loud boom). If the square contains a tree, the tree will catch on fire.
- At each time step of the simulation, if any tree has a burning tree within its Von Neumann neighborhood (of distance 1), it will stay unburnt with probability PROB_TREE_IMMUNE (initially set to .25). Otherwise, it will catch fire from the neighboring tree. (Note that this “immunity” is a per-generation immunity; trees which have burning neighbors and which prove to be immune for one generation are not necessarily also immune the next generation if their neighbors are still burning then.)
- At each time step of the simulation, if any house has a burning tree (or house) within its Von Neumann neighborhood (of distance 1), it will stay unburnt with probability PROB_HOUSE_IMMUNE (initially set to .5). Otherwise, it will catch fire from the neighboring square. (Ditto comments about the duration of “immunity,” above.)
- Trees and houses both burn for TIME_TO_BURN time steps, after which they are consumed and become empty squares.
- The simulation should run for 200 iterations and then stop.
- When it runs, your program should show an animation of the forest over time. Use the color green, and the marker “^” for trees. Use the color orange and the marker “D” for burning squares. Use the color brown and the marker “p” for (non-burning) houses.The key measure of your simulation (dependent variable) will be the fraction of houses that burn down.
Building this thing was a blast. I had the opportunity to start from scratch, so I started from the ground up with an object-oriented approach; each cell in the grid is considered as its own object.
If I had the opportunity to do it again, I think I’d decide against the object-oriented approach. I have no problems with using it, I’d just be interested to see how I could code the same simulations using a functional schema as opposed to an object-oriented one.
You’re a data scientist.
For CPSC 420, Modeling & Simulation, I was given the task of analyzing a huge amount of text, then simulating the author of that text writing some more. It involved comparing the frequency that words existed next to one another, eventually resulting in some crazy result that initially freaked me out.
I started the program from scratch; I wish I hadn’t. There currently exists quite a few libraries that are useful for analyzing text based on unigrams, bigrams, trigrams, or even n-grams. Those libraries would certainly be easier to implement than the way I did. Regardless, it was a fun experience figuring out how to make it work proper!
If you’d like to run it yourself, here’s what you do (for Unix or Mac users, sorry Windows):
- Go to https://pastebin.com/cvTXnnm8
- Click the Download button.
- In your Terminal, cd to your downloads directory.
- In your Terminal, type ‘mv cvTXnnm8.txt ngram.py’
- In your Terminal, type ‘python ngram.py’
Make sure you supply a lengthy text file (.txt) and pass it in when you run the script. Otherwise, it won’t do anything.
You’re (barely) a developer.
When you’re assigned to implement the inner machinations of a project, there are three real outcomes:
- The project has been completed and all requirements are satisfied.
- The project has been mostly completed. There’s a requirement or two that you were unable to fulfill in full, however you did put effort into them.
- The project has been partially completed. There’s a few requirements you didn’t even get a chance to touch.
I couldn’t even begin to write about the number of factors that come into play here to determine which outcome you’ll get. Anecdotally, I can say that the presence of a good leader, overall team skill, and overall team motivation are just a few that play pretty big roles in the outcome you’ll get.
The Alexa skills had three real requirements to meet:
- Stream FM radio.
- Stream AM radio.
- Stream a selected podcast.
For the Alexa skills, we fell into the second outcome. We were able to implement the majority of our requirements without a hitch; however, we were unable to complete the last requirement. (which bugged us for days) Still, we were able to demo what we had with a moderate level of success.
At the end of the day, our end product represented the amount of effort we put into it, as all do. We put in the effort we thought was necessary, but we missed the forest for the trees and were unable to satisfy every requirement given to us. If I had the opportunity to repeat, I’d make sure that our motivations were made clear and we were ready to rock from the beginning. That said, our product still works for the most part, and would be a blast to continue working on! Who knows… maybe we will.
You’re (still) a developer.
Software development is an ever-changing field. Some of the best software developers always stay hungry to learn more about the newest tech on the bleeding edge. Staying on top of your game here is critical in order to remain important as a software developer.
After writing the requirements document for Gusty’s Helping Hand, I had the pleasure of being part of the team responsible for implementing a radio streaming service for Amazon Alexa-enabled devices. This required me to go beyond my comfort zone and figure out how to:
- Learn how to build an Alexa Skill
- Learn how to read existing documentation
Learning how to build an Alexa skill proved to be of great importance; it taught me how to search the internet and be resourceful. Believe it or not, people dislike being asked easily-answered questions… especially if it interrupts their workflow. Being resourceful allows you to answer those questions yourself, but also gives you the mindset that you can solve just about any problem you know how to search for. Being a developer is arguably 60% Google searches and 40% code, from what I’ve seen. The trick is to retain that information so that the next time it pops up, you don’t need to search it; you already know the answer.
You’re a developer.
In the lifecycle of software development, there’s a pretty good chance you’ll come across a requirements document. Documents like this are designed solely for the purpose of demonstrating the specifications the final deliverable should have. The planning and design these documents often generate is almost mandatory to have in a successful project. Nevertheless, projects continue to be built without a document detailing the client’s requirements.
Why? Scenarios change. No two projects are the same. Smaller clients might interact more casually; the specifications may be easier to glean from just having a conversation with the client. That’s cool and all, but there are many scenarios where you can’t just click with the client and immediately begin implementing their ideas. You need to get on the same page first. Best way to do that is to look over a requirements document with them and ensure all has the green light.
Rachel Mooney, Sarah Gardiner, and I wrote the Requirements Document for Gusty’s Helping Hand, a ARM assembly language emulator. The process of generating this document was by no means difficult; it just took time. We spent our time discussing the requirements with Gusty Cooper, the client. The majority of our time was spent figuring out how to take all the great information he relayed to us and put it into a document that properly represents his vision. After all, the team ahead of us would be far behind in implementation if they had to pick up the slack and figure out what Gusty’s intentions really were first.
If given an opportunity to repeat the process of developing this requirements document, I would not change much. I feel like our general process had the right parts, but it would never hurt to continue asking the client more about the information they gave and how to make it proper in the document.
According to our client, we wrote a pretty decent document that matched his vision well. If you don’t believe me, see for yourself.