Registration date:
Post count: 31
My name's Stuart and this is my personal blog, I'll be recording what I learn at the Software Guild here.
All Posts
Edit Profile

Posts from this user

Week 7: Things move fast!

tuzgai posted at

Time's been flying and I haven't had a chance to post an update in a bit. Last week we covered SQL and the conceptual foundations of relational databases. A bit later if I have a chance I'll do some writing posts on ACID and how relational databases work. The big takeaway is that your programs are dramatically more userful and easy to write when you don't have to roll your own data storage. It was exciting material to learn, while obviously this site has a small database running behind it, I now feel much more prepared to add more complex features like tags or user groups.

This week we're covering JDBC - integrating database access into our Java code. So far it's pretty straightforward and we've learned some nice Spring Boot features to make wiring our dependencies together much more simple. (I imagine, I'm still having a little trouble getting my updated vending machine to run.)

In other news, Monday was the final cutoff for the first half of the course's projects. So far it looks like we only lost one person. It's disappointing - he was a cool guy and just a little behind conceptually. I'm sure he'll do fine when he retakes in the spring.

Now that the 'getting a job' side of the program has spun up, I'm working on cleaning up my LinkedIn, resume, and GitHub. It's kind of fun, I feel much more confident about pitching my skills now than I did a few weeks ago.

Last edited Permalink

Writing Warmup: Version Control and Git

tuzgai posted at

Prompt: Describe Git and version control and why we are using it.

As the size and complexity of projects increases and teams grow to more than one member, version control becomes an important concept. There are a variety of major benefits of version control:

- Changes can be rolled back.

- Multiple team members can work on different elements of the project and defer integrating their changes until they're done.

- Major changes can be separated into branches so that development of new features can continue while the current release is also supported with bugfixes.

Git is a specific version control software package that supports tracking the changes to your codebase, branches, pull requests, and a variety of other useful features to facilitate teams of varying sizes to contribute to a project. While Git initially took off due to its use in the development of the Linux kernel, a variety of sites such as GItHub, GitLab and BItBucket have facilitated public Git repositories.

This is very useful for open source projects and web-based tools have made contributing much simpler than Git's core command line interface. Not to mention, they have become a sort of 'social media for developers' that allow developers to publicize their work and solicit help. In our class, we use a Git repository hosted through BitBucket to submit and revise assignments.

Last edited Permalink

End of week 5

tuzgai posted at

I'm home sick today so I thought I'd take a few minutes to post an update. This week was 100% a working week on the Java 'mastery project'. Essentially we're learned all the Java we're going to in this class, so we spent the week demonstrating our skills and building another console-based CRUD app. This time the project was to build an order tracker for a flooring company - there was some basic calculations and validation for each order as well as a little complexity in managing the files in which orders were saved.

I'm still pretty dramatically ahead of the rest of the class. As of Thursday's stand-up, all but maybe 3-4 students had spent all their time catching up from the vending machine project that was due the 4th, while I finished the mastery project Thursday. It took me a solid 20 hours to put together so I hope they're able to make the time to finish before its final deadline of 3/1.

I'm looking forward to getting some exposure to SQL next week along with the start of the job-search track. We'll be doing a resume workshop next week and after that I'll probably start sending out applications. Now it's sort of a 4 day weekend for me! Maybe if I'm feeling better later I'll put in some time improving this blog site.

Last edited Permalink

Text I liked from the mastery assignment

tuzgai posted at
"We have covered all of the technical skills needed to complete this assignment. It is your job to think critically about this project, ask clarifying questions where requirements and features are not clear, and come up with a solid design and game plan before you begin coding. It is essential to your success that you don’t just “throw code” at the problem and hope that something sticks. We want you to use the background skills and techniques covered so far to synthesize a solution to this problem." Exciting! Permalink

Managing Cognitive Load or: How I Learned to Stop Worrying and Love Unit Testing

tuzgai posted at

We just hit the one month mark in this course and I think I've identified the biggest issue my classmates are running into - managing cognitive load. When you're making an application of non-trivial size, there's a lot to keep track of! There's the overall architecture, the implementation of each component, the user experience and so on. I think that, much like [how we think we can multitask but can't really](https://hbr.org/2010/12/you-cant-multi-task-so-stop-tr), we think we can hold a whole large program in our heads, but can't in reality.

I've been helping a number of people in my class with their project and the common theme is that they're always jumping around through their code chasing bugs, changing the architecture on the fly and generally feeling chaotic and overwhelmed. This was me not too long ago! But now, I'm generally not too stressed about these projects. Part of this is definitely because I have a head start in programming experience, but I think a big part is that I've given up on holding the whole thing in my head and rely on tools to help me stay organized and focused.

Much like how object oriented programming allows for separation of concerns between modules of your codebase, diagramming and unit testing allow for separation of problem solving and writing code. When you only have to hold one relatively small part of the problem in your head, life is easier and you work faster and hit fewer bugs. This might not work for you, but it's been a huge deal for me - give it a try!

Diagramming Before I write a line of code, I step back and solve the problem on paper or in diagramming software. I sketch out the classes and methods I need and their relationships and if the user interaction is complicated I do a little flowchart to organize my thoughts. None of this is necessarily for anyone but me, but what it lets me do is work out what the overall problem is and the steps to solving it before I get tied down reading the docs for BigDecimal or whatever. Once my diagrams are done, I can move on to implementation and know that if I am ever unsure of how things are supposed to fit together, there's an easy reference nearby. I don't ever think "Ok, what needs to happen next?" because I can just look at my reference. This has saved me a lot of time and energy.

Unit Testing Unit testing works just like diagramming but on a method level. Here's a frequent workflow for writing a method I see in my classmates (and in myself before I learned unit testing two weeks ago ;)).

1. Write a void method signature with no inputs

2. Write part of an inner loop, then go back to add the relevant inputs for the method signature

3. Go back to the code that calls the method to look at what it needs to return, update that.

4. Fiddle with things until Netbeans doesn't have any red lines.

5. Write a tiny console interface to test the method by hand

6. Jump around between the previous steps fixing things until it seems to work. This is a chaotic approach and means that your method is never truly finished - there's always the chance that you hit a big either from the method being incorrectly written or from a mismatch between your understanding of its behavior and it's actual behavior. In contrast, here's a workflow with unit testing.

1. Determine the desired inputs and outputs for the method. You now understand the shape of the problem.

2. Write unit tests to match your understanding of the problem.

3. Write your code.

4. Run unit tests and fix your code until they all come back green.

This approach gives you the opportunity to think deeply and understand the problem at hand before trying to solve it. It also gives you an easy answer as to when you're done. Finally, you can move forward and write code that depends on the method with confidence. It's unlikely (depending on the quality of your tests) that the method will behave in an unexpected way - you have already proven to yourself through your tests that it works correctly.

tl;dr Embracing diagramming and unit tests has been like night and day for the way I write code. Where I once jumped around tackling whatever problem interested me first and chasing bugs as they arose, I now make a plan and execute it with dramatically fewer bugs and delays. As a bonus, I finish the day feeling fresher since I wasn't constantly straining trying to hold the whole project in my head. If you're learning to code and don't do these things, give them a try!

Last edited Permalink
Newer Posts Older Posts