Category Archives: Coding

Week 8 blog Post

For this week I found an article about writing code considering we have been writing classes for the past few classes. The article I found stuck out to me because of its title “Writing Code an Art Form”. People always use the analogy of code being like learning a new language but I never heard anyone consider it as art. From the countless articles I could have chosen without this title, I may have never chosen it to begin with.

This article first starts with a background of how the idea of this article came to be. The setup was that the author was working as a junior developer who had to get a recently hired senior developer with 10 years of experience acquainted with their program. I can only imagine how that interaction was set up and whoever was leading the group should have probably reconsidered who should help the new employee. Even though the senior developer had far advanced experience his code was not easily readable. The author was even taken aback because the senior developer commented how the author likes to write pretty code. The author goes into detail on how poor documentation must be taken into account because other flaws can arise from bad naming conventions for variables/functions, spacing, and having the mindset to problem-solve. Keep the code easy to maintain, read, and debug don’t write spaghetti code.

Now reading this article gave me insight into the inner workings of the tech field. I would have never assumed that a new employee would be getting trained by the second recently hired. I would have assumed that someone with more experience with the project would have filled in the new person but maybe it could be that there both coming from similar places. Both of them are the newest employees and could be easier to help another person adapt to the environment. Reading this article has also reinforced ideas that keep your code simple and clean. My main takeaway was whenever you write code don’t just write it for yourself to understand but for everyone. Let’s say you are working on a project on your own you might just get enclosed in how you understand code nobody but you will be able to update it. Even if you don’t care that someone else will update it in the future your code can be so unreadable that future you may have no idea what you created. In a way, code is like writing notes and there is an art to writing good notes.  

https://hinchman-amanda.mehttps://hinchman-amanda.medium.com/writing-code-an-art-form-e41e459bd2f6dium.com/writing-code-an-art-form-e41e459bd2f6

From the blog CS@Worcester – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 14 – Token #1 – CS343

For this blog I’ll be using one of my tokens for this class so I can hit the 6 blog minimum before the semester is over.

In this blog post, I wanted to look more into JavaScript since I didn’t really know too much about it. I struggled with the backend homework we had because I never knew anything about the syntax or language at all. So, I want to learn a bit more about this language within this blog. For this, I consulted this website, and gave it a good hearty read:

https://developer.mozilla.org/en-US/docs/Web/JavaScript

This site gives an overview of JavaScript and the applications in which it is used in general, and what benefits and downsides it has compared to other languages.

What I found very interesting is that I originally knew that JavaScript was mainly used for website development and coding, but this site gave some examples of applications such as Node.js and Adobe Acrobat. I believe we’ve actually utilized Node.js before in our classes, but I can’t quite put my finger on what exactly we used it for, but I recgonize the name appearing in one or more of the repositories we’ve been working with.

It seems like JavaScript is much like Java in the sense that it can use object oriented code, but I think the similarities between the two end there. In the past, I always heard that JavaScript was a completely different beast from Java, and after look more into it, I see why. This site below describes the differences:

https://www.lighthouselabs.ca/en/blog/java-vs-javascript

JavaScript it object-orientedcode, whereas Java is object-based. That may sound the same as each other, but there is some very specific distinctions between them. Java relies on objects to function, whereas JavaScript has functionality for objects and suggests use of them with it’s language, it is not required. JavaScript is also a lot more fluid with it’s syntax, and has a lot more free-form and flexibility with it, which reminds me a lot of what I’ve heard about Python. Java is a lot more rigid, and requires specific pre-set uses of it’s syntax.

But back to JavaScript, it seems like its The language for web design, as a lot of it’s language is made with web design in mind. My future for this area of study is some form of design in technilogical areas, so it would be possible I go into Web Design. If I do, I’ll definitely have to teach myself more JavaScript. It seems like a really useful language to have on hand in that case.

I will be posting one other blog today, using another token, so stay tuned for another!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Summary

In this sprint, I mainly did the following things:

What Worked Well

In this sprint, I had a lot of clear feedback from the prior sprint. This allowed me to very quickly knock out a lot of work in the first few days. It was very simple to go through and make all of the required changes.

What Didn’t Work Well

In hindsight, I should’ve made those “backend modification changes” one card. Instead I had four separate cards and four separate merge requests. It would’ve been cleaner and faster to have one card for it all.

Similarly, having finished those tasks so quickly left me at a loss of what to do for a while. I ended up helping some team mates out with a few things, but eventually I settled on working on the docker aspects of the system. I then ended up spending a lot of that time helping myself understand how it worked and wasn’t able to make as much progress as I otherwise would’ve liked.

I also think that simply due to the nature of the end of a semester, we didn’t really have the time to work outside of class on this. I personally had two projects I needed to create as well as a lot of studying to do. It was also hard to resist planning out my summer in my free time since I needed to buy thing and make plans for my summer of biking, tennis, and grass mowing.

What Changes Could be Made to Improve as a Team

Once again, we overall worked pretty well together. I’d say initially our team didn’t really do too much together. Everyone was working on their individual components and so we didn’t communicate as much as we might’ve been able to. That said, later in the sprint when we actually did need help on things, we all were able to come together and figure things out.

Supposing we were ever to work together as a team, I think we could improve by being more vocal and more unified. I think most of our problems though came from this being a course as well as us being mentally done with the semester. If this were a continuous job, things may have been naturally better.

What Changes Could be Made to Improve as an Individual

In this sprint, I didn’t do as much work I could’ve done. I could’ve asked if my teammates needed help on things and worked on the frontend, for example. I could’ve had a better attention span and self control near the end of semester.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Share What You Learn

The problem of this pattern is one of the final ones, as far as I can tell. It is framed around your near-completion as a developer. I mean this in the sense that you’re a rounded-out developer with a lot of useful skills, but not necessarily a significant amount of real-world experience. In order to truly become a journeyman, you need effective communication skills. It isn’t enough to be a good programmer.

In order to gain such skills, the proposed way is to share that which you have learned. One such way is via a blog such as the one you’re currently reading. I pretty much completely agree with this pattern. I think the best way to learn things is to explain them to someone else. Really, the reason that we are tasked to write large essays in high school and college, despite them being annoying, is because writing is thinking. If you are capable of reading these words, then you’re most likely literate. Modern people take literacy for granted. For millions of years, the vast majority of humans were illiterate and as such their brains developed in a different manner to ours.

According to a discussion with Psychologist Jordan Peterson (that I unfortunately cannot find to link here), illiterate people think differently than literate people. Illiterate people think more in images and experiences, similar to how animals think. (Don’t let your arrogance get the better of you; all humans are animals biologically.) Words themselves are abstractions and your brain has to handle abstractions differently. It has to convert from symbols and sounds to the word to the meaning of the word. I would say that tribes of people that rely heavily on the oral are similarly affected. Nonetheless, literacy has a profound effect on your brain and thus how you learn. Writing is a form of thinking. Literate people have the ability to write or type words without really planning it in their minds, similar to how people can speak without thinking. The words are the thinking. So, when you explain something, you need to find the words to describe it and that process is thinking.

That’s why written words can be so messy; we think through them as we write. Thoughts are messy. So, it is essential to be an effective communicator not only to benefit others. Ignoring the existence of other people, being an effective communicator means you are an effective thinker. This is specifically in terms of words, which I would argue programming requires. The concepts dealt with in programming require intense mental abstractions that most of us take for granted. There’s a reason the general population thinks coding is magic. It’s simply too abstract to fully grasp from a single viewing. This means words are the way we handle that abstraction. Thus, make yourself powerful with words in order to become powerful in your actions as a programmer.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Practice, Practice, Practice

The focus of this pattern is the simple idea that practice makes perfect. The problem arises from the fact that every time we code, we’re practicing. We try new things, we make mistakes, and we learn. However, when the majority of our code is for work, making all of these mistakes is sub-optimal in numerous ways.

Similar to previous patterns, the proposed solution is to practice outside of work. Do coding exercises for fun and learn from them so when you go to work, you can make fewer mistakes. I would mostly agree with this. My biggest criticism is the same as in a previous pattern; not everyone has the time outside of work to keep working. Depending on the job, it would require a person to live and breathe programming. They would need to use their free time, which is intended to keep the individual sane as well as give their mind a break so they can keep coding the following day. This could have overall worse consequences. For example, I’m capable of coding for virtually eight hours straight and I have on occasion. However, I almost always feel brain dead afterwards. Sometimes, I need a few days off afterwards to be able to think about coding again. As an athlete as well, I can say do not underestimate the importance of rest.

That said, I fundamentally agree with the notion of purposeful practicing. I started teaching myself programming in middle school and it was really slow and hard. The times I learned the most were when I could follow a well-made guide to create something simple. As I developed as a programmer, however, I was more easily able to guide myself through these projects. When I learn a new language, I often create a primality test. It introduces me to io, iteration, efficiency, data types, etc. in a language. Often, I’m unsatisfied with the maximum size of a 64bit integer and I start trying to create a larger integer object that can run efficiently and store large integers. This leads to learning even more skills in a language. However, there are books of prime numbers that go into absurdity. These projects aren’t really meant to have a utility outside of making them. This is what the author means by deliberate practice. I’ve spent years teaching myself different technologies and the most successful ways have always involved some sort of practice project. If nothing else, they make you really good at researching.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Stay in the Trenches

The problem in this pattern is an extremely simple one; you are a programmer at a company and you are offered a promotion that will take you away from programming. The provided solution is basically to just stay in programming despite the opportunity.

I would say I mostly agree with this pattern. This reminds me of Star Trek Beyond (2016) where spoilers, Kirk is offered a promotion to, what I believe is, Admiral which would mean he would no longer fly. After a long adventure, both him and Spock realize that where they belong is on the Enterprise together with the crew. So Kirk turns down the promotion. I think this situation – in a very decent film that most people seem to overlook – is a great match for this design pattern. The motivations are only partly the same, however. In the film, Kirk chooses the Enterprise because he is driven to explore. This design pattern, however, cares primarily about your future career and skills.

There is obviously an implication that the software craftsman enjoys programming, but the main reason they give for turning down the promotion seems to be that you need as much software experience as possible. If your career goal is to be in software, then being in a higher level position at some company you’ll probably leave in a few years doesn’t help you as much as being in programming. There are also potentially alternatives to a promotion that still accrue you the benefits you’ve earned.

Overall, I would say I’m in agreement with this pattern. You need to focus on your long term goals. In this scenario, that is most likely to become a good programmer. That said, its up to you to gauge the opportunity in front of you and determine whether or not it matches your goals. Perhaps the company you are at is a solid position with little fear of losing the job. Then, maybe you should take the promotion and simply keep climbing up. Its okay to change your plan in the face of new opportunities. The key is that you’re thinking rationally and properly about the situation at hand. After all, its your future.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Craft over Art

The problem of this pattern is a very common situation; virtually any time you are building something for a client. You are tasked with producing something that will solve the client’s problem. While you could follow a basic, common method, you also could explore new solutions and build something more custom. The pattern then determines that the solution to this problem is to rely on the tried and tested method. The justification is that your job is to create something functional and you must prioritize that over all else.

I’m not sure how I feel about the proposed solution to this. I would say I overall disagree. Firstly, just because you’re trying something new doesn’t mean its entirely original. There are varying degrees to which you could try something new. So I disagree with the absolutism of the statement. Next, I don’t think that taking the time to create something new is entirely selfish. Just because you could hack together something functional quickly and deliver it to the client doesn’t mean that they won’t have a successful, or even better product from you creating something original. In fact, I think in a sense it shows how much you care for the client. Rather than giving them something cookie cutter, you chose to think specifically about their problem rather than force it to match some other problem. When it comes to coding, that practice might significantly aid performance, for example. Cookie cutter solutions to intensely computational problems can’t be as efficient as specified unique solutions.

Lastly, not all developers have the time to create original content in their free time. If developers spend all of their time copy pasting the same projects, how will the industry as a whole ever advance? So once again, it isn’t just about advancing your own individual skills. I feel there is a disconnect with this pattern. The author seems to be referring specifically to artifying the job, but their descriptions are much more vague than that and can encompass less “negative” practices. When it comes to treating every job like a unique art piece, I’d generally be against that since I don’t think it is a good business model. However, it depends mostly on what the client wants. Perhaps the client wants that level of connection with the craftsman.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Testing in Python and Sea

Something that is worth noting is Python’s assert keyword. Python has a built in way to create basic unit tests beyond simply printing and making comparisons. This has me thinking about my Sea programming language.

I think much of the hassle I’ve had with unit testing has come from simply getting the environment set up in the first place. If unit tests could be more like a data structure or design pattern – something you know the design of and you can simply implement – I think that would simplify a lot. So while I could create a Sea library for unit testing similar to numerous other libraries (or wait for someone else to make one in Sea), I’d prefer to create a more internal solution.

Sea is fundamentally C, so that means it doesn’t have a lot of high level features that can make unit testing easier. I mean, Sea isn’t even object oriented. That said, the entire design philosophy behind Sea is based on simple syntax that doesn’t add a runtime performance cost. One way I could achieve this is by adding another “stage” to the language. The current design of Sea involves a preprocessor, a lexer, a parser, and a visitor (interpreter, transpiler, or compiler). What I could do is add a tester that would run before the visitor, to test compile-time things (checking types or any other value known at compile time) and then a runtime tester. These could be modular features of the language itself and could be removed if desired.

Another simple solution is to add a handful of keywords to Sea similar to assert. The problem with that is C doesn’t have runtime exceptions. The design would have to be based on the notion that the program is the unit tests. I’ll continue to think this over. After all, Sea is still in its early stages. I’m currently rewriting it (just on the visiting functions now) and then I’ll add functions, pointers, etc. However, if Sea is to become a real, usable language then there will have to be ways of testing code; the simpler and more convenient, the better. After all, that’s the whole point of Sea.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Converting a Project to Gradle

A few weeks ago, a few classmates of mine asked for some help with converting code to Gradle and I created a quick guide. I’d like to go through and create another guide with more detail.

Assumptions

  • You have Gradle installed.
  • You know which language you are using.

Instructions

The first step is to run gradle init in the project folder that you wish to convert to gradle. I would recommend if you’re unsure about the process or the settings you’ll use, just create an empty folder somewhere and practice creating a gradle project in that. Then, delete it.

Note that depending on the options you choose, you may be asked questions I do not cover here. Just do your best to figure out what it means and use the internet for research. Worst case, you can always modify the settings afterwards.

When you run gradle init, you will be asked some questions about your project. You simply type the number corresponding to the option you want and then press enter (or simply press enter without a number for the default option). In our classes, we always used libraries. If you have a main method, you’ll probably want application.

Next, it will ask you for the language you want to use. This is probably the simplest question. In our classes, we’ve used Java but you can use any of the displayed programming languages.

Next, is the build script DSL. If you don’t have a strong opinion on this, just use the default.

Similarly, next is the testing framework. Use whatever you’re comfortable with. In our classes, we’ve used JUnit Jupiter.

Next you can name the project anything you like.

This last step where it asks for source package for Java is a step where many people mess up. The default option is an undesired package name, since it will include capital letters. I recommend using a lowercase package name.

Now, you can open lib/build.gradle. You can remove the lines and comments for api and implementation. These are auto-generated, but not necessary. Next, if you plan on using GitLab’s ci, modify the testRuntimeOnly line. Notice how the testImplementation line has a version number following a colon. Modify the testRuntimeOnly line so it has the same version as the testImplementation. After these steps, my dependencies looked like this:

dependencies {
// Use JUnit Jupiter API for testing.
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.2'

// Use JUnit Jupiter Engine for testing.
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.6.2'

}

Now, gradle will have created a gradle/lib, gradle/app, etc folder. Locate your package which will be a subdirectory of gradle/lib/src/main/java in my case. The main folder will contain your source files and the test folder will contain your tests. Move all of your source files into main/PACKAGE_NAME and move all of your tests into test/PACKAGE_NAME. You can delete the files gradle generated for you.Then, if you’re using java, you’ll need to go into each java file and add a package declaration. Make sure its the first line and that there is only one. It should look like:

package PACKAGE_NAME;

Where PACKAGE_NAME is replaced with the package name. You can then run tests with the gradle test command. If you want to have GitLab run your tests for you when you push a new commit, download .gitlab-ci.yml (ideally the newest version so not from this link) and add it to your repository. Now, things should hopefully work.

Closing Comments

It’s taken us a while to become familiar with Gradle so I think it was worth me writing all of this down (albeit hastily) to help other people in the future, and especially to help me remember it if I ever use Gradle again in the future.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Testing Functional Code

In programming, it is essential that developers can ensure that their code works as expected. One way to ensure this is unit testing. However, unit testing and many of the general testing styles are only convenient and simple for basic types of projects. For example, unit tests are great for public libraries made up of classes and functions that can easily be tested. Not only is it easy to test these, but it is simple to understand. You just make objects and call methods and check the results. However, not all code is made up in that fashion.

A clear example of this is a programming language such as my Sea language. In theory, I could take a few weeks and create proper tests for everything involved. However, creating production-level unit tests for a project of this size by yourself is tedious and time consuming, to say the least. One way I find convenient to help test my language is to simply create a sea file with code I want to test the interpretation/transpilation of and then run both the transpiler and interpreter to check the results. Another thing I did was add a debug option to print out the generated tokens, AST, and memory.

This is admittedly janky. There is no standardization for my testing process. Luckily, most of the problems I run into either generate a Python exception, or an obviously incorrect output. That said, maybe that’s only because those kinds of problems are the only ones I find and there are tons of hidden errors that are laying quietly. That overall is one of the best things about Python, and my motivation for Sea. In Python, it is really easy to write thirty lines of code and then run it and have it execute without any errors. This is because the syntax is so simple and readable that its easy to find errors before you even run the code.

Sometimes, I think its alright to not properly commit to testing code. Code that relies more on user input than parameter input (what I’ve called functional code) can be incredibly challenging to properly test. For instance, if I were to properly test Sea, I would need to create sea files that have almost every combination of valid syntax. Not only that, but I’d need combinations of valid and invalid syntax as well to make sure the code finds the errors. The point of testing is to save time and to ensure valid code. In the case of a programming language, I think its easy enough to ensure valid code and in exchange you can save almost half of the total time you’d otherwise need to be spending.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.