Cellar Door Blog

In this week’s blog we’ll talk about peer review, sometimes known as a code review or walkthrough.

What is it?

This is a thorough technical and logical line-by-line review of code. It is usually done in a small module, like a program, subroutine, object, method, etc. Sometimes a meeting can be held to discuss any issues related to the revision.

Why?

One of the main objectives of this process is to identify possible improvements and ensure that business requirements are met. 

Advantages, disadvantages

A lot of programmers complain about code reviews because they think it takes a lot of time. This may be true in some cases. Nevertheless, the drawbacks are usually outweighed by the benefits. The main advantages of this process are the following. First of all, it helps reduce bugs. In the long run, all that work will be significantly less if you find those bugs later on when the project is much advanced. That means less rework. There’s also more team communication. All of this helps to improve the team cohesiveness.

How does it work?

The methodology varies from company to company but most methodologys follow this 3 step process consisting of preparation, review, and follow-up. Here’s a look at each step.

Preparation

First, the code being reviewed must be complete, tested by the programmer, and in the programmer’s view, ready for the next step in the development life cycle. The code and other affected project components, such as documentation, test cases, a project schedule, or requirements changes must also be available to the review participants

Review

Reviews are conducted as needed, usually based on the rate of code output. The frequency of individual participation in a peer review depends primarily on the size of the programming team. A team of three programmers might include all three in every review. Larger teams might be able to rotate participation based on experience, skill level, subject matter familiarity, or site-unique factors.

Follow-up

Follow-up provides evidence of the meeting’s success and incentive for the continued use of reviews. The value of future reviews will be degraded if decisions are not enacted, and eventually programmers will view the process as just another waste of time. Follow-up is critical for all participants, especially the programmer. The documentation must be kept in a central location where anyone can reference it.

References

Developer’s guide to peer reviews

https://smartbear.com/learn/code-review/guide-to-code-review-process/

The customer is always right

The first step into writing good code is to make shure that you application works just like the customer wants it to. A good thing to remember is that the customer will never care about use cases and diagrams. They want to see your software acually doing stuff. So no matter how good your list of features and how pretty your diagrams are; if your software doesn’t do what your customer wants, those pretty diagrams aren’t worth anything.

Use case driven development

In this approach you focuse on one scenario in your use case diagram. You must code all the scenarios in one single use case.

Feature driven development

In this approach you start off with a specific feature and before moving on to the next one you complete the previous feature fully.

Which one do I like more?

I like the use case driven development more. I think the FDD is not optimal. I feel like most of the time, the features are all inter-connected. This makes it difficult to code. Of course, if your features are all independent from one another there’s no problem. What I think it’s that most of the time this is not the case. Maybe a few features are independent. But in my short experience the difficult and important features are always dependant on one another.

My take one this chapter

On this chapter they described a series of design principles. A lot of them were things that we kind of knew but it is really important to keep in mind and acknowledge their importance. The principle that I think it’s the most important one it’s the Don’t Repeat Yourself Principle (DRY). This one is the principle that I’ve broken the most.

My bad practices

When I’m breaking this principle I get the feeling when I’m doing it that it’s something bad. Most of the times it’s pure lazyness. I kinda know what I’m suppose to do to follow this principle. At first I tell myself that I just want to make things work and not worry about fancy things. But when I’m done with the things I wanted to “just work” I’m afraid that if I change something I might break my code. It’s a funny cycle I keep getting myself into.

An example

When I was doing a project with a friend that wasn’t from the school I broke the DRY principle several times. I had to connect to a database and I had to do it from several files. What I was wrongfully doing was that I wrote the information to connect to the database in every file. So I had an options object with the name of the database, password and username in every file. This is wrong in multiple levels. First of all, if I wanted to change the database the I connect to I would have to check in every single file for the name and change it. Secondly, the password was written in a lot of files of my project. If I upload my project to github it would be disastrous. In both cases I need to make a different file where I store the information and export it. And in every file that I need that information I import it. Finally, I would add this specific file to my .gitignore file, so that it is not uploaded to github.

What I should do

What I should strive to do is to start making things right from the very beginning. I think most of us programmers don’t do this because we sometimes feel like we’re not making any progress. It is difficult to do things right from the very beginning because we sometimes don’t know how.

Installing

Installing the game was easy. The problem is the Java jdk. In a previous project for my advanced database systems (it’s not “advanced” actually, it’s just non-relational databases) I had to modify my JAVA_HOME path in my system variables. After fixing that I ran the game with no problem.

Version

I played the XP and the waterfall versions.

Gameplay experience

I’ve never heard of a game like this so the experience was unique. I had no idea if what I was doing was good or not. I just went with my gut feelings. It was very fun because all of my classmates were struggling with it.

Difference between XP and waterfall

In the XP mode you had very little options so sometimes you couldn’t do anything except skiping to the next event. On the other hand, in the waterfall version, you had too much freedom. You could fire people, you could lower their wages and you could give them bonuses. I prefer the XP version because the waterfall version overwhelms me with choices.

I got a score of 25 in the XP version. I didn’t finish the waterfall version 😦

If you already did the design and draw a class diagram in UML then you’ve already done the hard part. Now you have to follow what you diagram says.

Attributes

I can use the class diagram that I did for my mid-partial project for my Object Oriented Programming course. At the top we have the attributes of the class Contacto. To turn this into code you have to pay attention to the sign (this will be the acces type) and type variable. If there’s a minus sign you make the attribute private. If there’s a plus sign you make the attribute public. Then you just make it a String if it says that your attribute is a string.

Methods

The acces type rule still holds here so there’s no need to explain it again. What you have to look for is the values the method recieves and the return type. For java these things really matter but for languages like python or javascript it is not that important.

Relationships

You need to pay attention to the relationship between you classes becuase it directly affects the code. With inheritance you need to specify which class it extends from (if you’re in java). There are also composition and aggregation relationships, when there’s such a relationship you’ll need to create another attribute to the class.

Now, which programming language?

Mobile apps

Native

IOS – Swift

Android – Kotlin or Java

Hybrid – which Framework

React – Javascript

Vue, Angular – Typescript

Flutter – Dart

Back-end web development

Ruby

Javascript

PHP

Python

Server side application

Rust

Go

Games

For consoles

C++/C# along with the unreal framework

For desktop

C# along with the unity framework

Data Science/Machine Learning

Python

R

To create a static website

HTML CSS

Web app

Javascript

References

https://www.27global.com/how-to-choose-a-programming-language/

From Models to code with no mysterious gaps – interview with Leon Starr

This chapter

This chapter talks about what to do in big projects when you have alreadey layed out the features. They try to write some use cases but it shows that it is a little bit difficult writing perfect use cases just yet. Insead they write what they call scenarios . These help to actually start writing use cases when you’re not quite ready yet. This chapter also talks a little about risk and how you must shift you implementation in such a way that minimizes risk. They also give you three tips to help you figure out where to start. Especially in these big proyects one can feel overwhelmed. It can be difficult to know where to start.

Where to start

The last chapter they layed out a very complex and big problem. We’ve done a very broad analysis of what the application must do but without getting into actuall code. In this chapter they help you decide where to start first once you’ve described the mayor features. Basically there are three tips that the books gives. Start with what’s essential (duh), start with what you don’t understand , start with what you don’t know how to do. The first one can come across as really obvious but it’s important to have in mind. The second what are very self explanatory. If you don’t know how to do something, you should start with that becuase otherwise it can cause you problems in the long run. I’ve experienced this myself. I was in the back-end of the development of a proyect and I didn’t understand how a specific thing worked on the front-end that was relevant for the task. I had to change quite a few things becuase of this afterwards.

Reduce risk

They also talk about a certain key aspect of software analysis. Risk. They say that everything one does in the architectural phase of the project should reduce the risk of the project failing. I can understand why this is very important but I haven’t quite totally understood it. I don’t understant why would that change if you do something first or leave it at the end. If a certain feature is at risk of making your whole project fail what does that have to do with when you do it. If a feature is going to make you fail, it should make you fail wether you do it at the start or at the end right? I don’t know but the book didn’t make it clear.

Scenarios b4 uses cases

When you’re in such a big project like the one in chapter 6 and seven there’s a lot of room for mistakes. And you also feel overwhelmed by the size of the project so it’s hard to go straight into writing use cases. This is probably one of the most useful things of the chapter. To write scenarios of how you’re application will work is useful to start writing use cases.

Strong entity types

A strong entity is one that doesn’t depend on the existence of another entity. For each strong entity create a new table. This relation will contain all simple attributes of the entity. For composite attributes such as name only include its simple attributes such as first name and last name.

Weak entity types

Also create a table from every weak entity. But the primary key will be composite. Consisting on the primary key of the strong entity and the weak entity.

Binary relationships

one-to-many (1:*)

The one to many is easy. The entity on the many side will have a foreign key. This will be the primary key of the one side. For example: if a cashier registers many sales. But a sale is registered by one cashier. The primary key of the cashier; let’s say cashier_id, will be a foreign key in the sales table. Because if it where otherwise, you will need a list of keys in the cashier table consisting of all the sales that this cashier made.

One-to-one (1:1)

The one to one relationship is a little bit more complicated. It will have three cases.

(a) mandatory participation on both sides of 1:1 relationship;

(b) mandatory participation on one side of 1:1 relationship;

(c) optional participation on both sides of 1:1 relationship.

mandatory participation on both sides

In this case both entities are merged into one table. We choose one of the primary keys as primary key and left the other one as an alternate key.

mandatory participation on one side

This case is a little bit like the one to many case. The entity that has mandatory participation will have a copy of the primary key of the entity that has optional participation. Why? This is because mainly we don’t want null values in our tables. So the mandatory entity we know will exist and thus its primary key. So if the optional exists it will always have the foreign key of the mandatory entity. If it were otherwise the primary key of the optional would be referenced in the mandatory entity. And the optional entity may not exists. So there’s a risk that there’s a null value on the mandatory entity.

optional participation on both sides

In this case one can choose. However, if we can identify a way that would lower the risk of null values. For example; let’s say that a company has cars that the staff can use if they choose to. A car may or may not have a staff. And a staff may or may not use a car of the company. However, the mayority of cars have a staff. And only a privileged minority uses a car. So in the cars table if we reference the staff id that uses that car there will be a few null values. If we would do otherwise, we would reference the car id in the staff table. Since a lot of staff don’t have a car associated with them then there will be a lot of null values in the staff table.

Many-to-many (*:*)

This is different from any other binary relationship. Becuase we create a completely new table. The primary key of this new table will be a composite key that will include the keys of both entities. Likewise, there will be a foreign key for each entity’s primary key.

References

I retrieved this information from the book of my relational database course pages 530-536

Database Systems A Practical Approach to Design, Implementation, and Management. SIXTH EDITION

Thomas Connolly adn Carloyn Begg

What is LISP?

When I first started reading I knew that Lisp is a programming language. But I don’t know more things about it. So I decided to investigate a little about it before I read the whole essay. Lisp is actually a family of programming languages. It is the second oldest high level programming language, Fortran is just one year older.

Standardization

One of the things that Lisp did right was it’s ability to became standardized. This effort started wy back in the early 80’s. There were efforts to make a standard version of Lisp even outside the US.

Good Performance

Many Common Lisp implementations have multitasking and non-intrusive garbage collection. This made Lisp very competitive in terms of performance. These features were regarded as impossible on stock hardware ten years ago. Lisp was competitive even to C.

Good Environments

In this essay. The case is made that modern programming environments are a result of the Lisp and AI tradition. Some of the examples listed on the essay are: the first bit-mapped terminals, the mouse pointing device, full-screen text editors, and windowed environments. These all came from laboratories engaged in AI research.

Good Integration

C, Pascal and Fortran can be invoked from Lisp code. Likewise, these programs can invoke Lisp. Such interfaces allow the programmer to freely mix foreign and Lisp functions.

Object-oriented Programming

According to this essay Lisp has the most powerful object-oriented extensions of any language. One can do things such as multplie inheritance that Java can’t do but C++ can. It has First-class classes and First-class generic functions. Along with a lot of other features. The author predicted that this Lisp will be the first standardized object-oriented programming language.

State diagrams

State machine diagram are usually implemented to describe state-dependent behavior for an object. An object responds differently to the same event depending on what state it is in. That means that it is important to define the state that you object is in to accurately predict its behaviour.

What is a state?

A state is an abstraction of the attribute values and links of an object. Sets of values are grouped together into a state according to properties that affect the gross behavior of the object.

Package diagram

In this technique each class is put into a single package. If a class wishes to use another class in the same package, all is well. If a class wants to use a class in a different package it must draw a dependency to that package. The overall picture of the system is the picture of packages and their dependencies, the aim is to keep the dependencies down to a minimum.

Component Diagram

Component diagrams are used to visualize the organization of system components and the dependency relationships between them. They provide a high-level view of the components within a system.

What is a component?

The components can be a software component such as a database or user interface; or a hardware component such as a circuit, microchip or device; or a business unit such as supplier, payroll or shipping.

References

http://www.cs.unc.edu/~stotts/145/CRC/package.html

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-state-machine-diagram/

The Easy Guide to Component Diagrams

This chapter

This chapter has been my favourite chapter so far. It’s been the one that I’ve acquired the most knowledge about things related to a proyect I’m involved with outside of school. I’ll later talk about what was the most useful information for me in this chapter.

Good things about this chapter

I like the case example that this chapter uses. The other ones have felt kind of gimmicky. They were kind of boring and I didn’t think they would be real applications that I could be involved in. This one feels a little bit more real. It’s kind of complex in my opinion because the initial vision statement really felt very ambiguous ang general. It feels like a really big project. And I like that. I’m very interested to see how they’ll tackle such a large project.

The project that I’m involved in

Right now I’m involved in a project outside school. It’s an app that my team has been developing. Right know we’re more in the testing phase. This chapter has been really useful. Reading this chapter I was always thinking how we could have done a better job if we thought the way that the book encourages us to.

Start thinking big

One of the principles that the book talks about is that you always have to start thinking about how your app works in a larger scale. I think it is really useful for me because I always want to rush it and start coding right away.