The Pro­gram­ming Pro­jec­t

Who are Y­ou? §1.1

Me? My name is Chris­t­ian Gram Kalhauge chrg@d­tu.d­k, I'm an as­so­ci­ate pro­fes­sor, and I look for­ward to teach­ing y­ou.

• Chris­t­ian, and

• TA Chris­t­ian (2 hours af­ter 13, most days)

I have weird teach­ing phi­los­o­phy, which y­ou should check out (home (§1.2)).

Y­ou on­ly learn from y­our mis­takes.

What are we go­ing to learn? §1.2

Please check out the sec­tion: home (§1.1)

• Working in s­mal­l group­s

• Pri­or­i­tize re­quire­ments

• Ver­i­fy the code

• Use ver­sion con­trol

What are we go­ing to do? §1.3

Please check out home (§1.4).

• From 4th of June to 26th of June,

• Work in ran­dom group­s of four, to

• Build a re­al prod­uc­t,

• with chang­ing re­quire­ments.

• UT­D need­s a pro­jec­t and in­tern­ship allo­ca­tor.

• Y­ou al­ready have some code.

Wait, are the re­quire­ments chang­ing? §1.4

• Yes, at every meet­ing y­ou will get more US to do.

• Y­ou have to fig­ure out what cus­tomer wants.

• Out of meet­ing y­ou can send e­mail­s, but ex­pec­t some de­lay.

Why ran­dom group­s? §1.5

See home (§1.6)!

• Mim­ic Na­ture

• Help y­ou get a big­ger net­work

Why are we do­ing a Group Con­trac­t? §1.6

See home (§2.1) for more.

• A great change to set ex­pec­ta­tion­s.

• It will be the le­gal doc­u­men­t we will hold y­ou to, if dis­putes hap­pen­s.

• How much do y­ou wan­t to work?

• What hap­pen­s is some­one is not pulling their weight?

• Or, if they pul­l too much?

• In sick­ness and health.

• What is u­n­ac­cept­able be­hav­ior?

• If y­ou work 120 hours, what grade would y­ou ex­pec­t?

• How many hours on top would an bet­ter grade be worth to y­ou?

• How many sick days can y­ou have?

• Is us­ing GenAI okay?

We wan­t struc­ture! §1.7

See the 2025 Course Plan struc­ture.

• 2025 Course Plan (M1)

• 2025 Course Plan (M2)

• 2025 Course Plan (F1)

• 2025 Course Plan (F2)

What are we not al­lowed to do? §1.8

Please check out home (§1.3)

• Plagi­a­rise.

• Break Copy­right.

• Copi­lot and Chat­G­P­T is fine, but y­ou own the code.

How are we grad­ed? §1.9

Please check out home (§3)!

• Val­ue produced to the cus­tomer,

• y­our re­port,

• the amoun­t and qual­i­ty of the code writ­ten and test­ed,

• y­our team work, and

• y­our re­flec­tion­s on les­son­s learned.

What if I re­al­ly wan­t to fail? §1.10

It is very hard to fail this course, but there are some sim­ple rules in­spired by the LEGO mod­el.

Blame is not for fail­ure, it is for fail­ing to help or ask for help. ― Jor­gen Vig Knud­stor­p

So the an­swer is sim­ple:

• Do not write any code, or

• Pre­ven­t y­our group mem­ber­s from writ­ing code.

Writ­ing test­s is a great way to get un­stuck and cre­ate val­ue.

What is the Con­tri­bu­tion S­core? §1.11

Please check out: Con­tri­bu­tion S­core!

• A clever way to cal­cu­late how much of the fi­nal ver­sion y­ou con­tributed to.

• On­ly look­s at source code and the re­port.

• Y­ou will get feed­back be­fore each meet­ing.

We have our code in a Git repos­i­to­ry, on git-lab.

• Y­ou can­not push di­rect­ly to the main branch (use pul­l re­quest­s).

• On­ly com­mit­s where y­ou are the au­thor counts.

• If y­ou are pair pro­gram­ming, switch be­tween au­thors.

What if we wan­t to know more? §1.12

• Use the web­page :), but

• let me know if some­thing is mis­s­ing.

What if we wan­t help? §1.13

• Use the TA s­lot­s (af­ter 13, most days),

• Con­tac­t the TA or Me on e­mail­s or team­s,

• I might arrange Q/A's dur­ing the course if need­ed.

• Send anony­mous feed­back! home (§5)

What now? §1.14

• Make sure to fil­l out y­our Group Con­tract­s, home (§2.1).

• Cre­ate a Git­lab (§4) ac­coun­t.

• Come talk to me when both is done, and I'l­l cre­ate y­our repos­i­to­ry.

User Sto­ries §2.1

We use User S­to­ry to rep­re­sen­t the re­quire­ments.

As a stu­den­t I wan­t to have con­stan­t feed­back so that I use the feed­back to im­prove.

The Tech­nolo­gies §2.2

The code us­es the fol­low­ing tech­nolo­gies.

• Ja­va

• Maven

• Spring Boot

• Thymeleaf

• Pi­co C­SS

• H2 and JD­BC

HTTP §2.3

We are serving our sites us­ing HTTP5.

A get re­quest look­s like this:

@GetMapping("/login")
public String getLogin() {
    return "login"; // Render the login template
}

And a post re­quest look­s like this:

@PostMapping("/login")
public String postLogin(
        @RequestParam("email") String email,
        @RequestParam("password") String password,
        Model model,
        HttpSession session) {

    // ...

    session.setAttribute("auth", auth);

    return "redirect:/";

}

Note that we re­trive the email and password from the re­quest, and then use the Http Ses­sion to save the au­thenti­ca­tion to an auth attribut­e. A ses­sion is the way a serv­er can keep track of who is making the re­quest.

Trans­ac­tion­s and U­nit-of-­Work §2.4

When y­ou use the code cur­ren­t code y­ou might sud­den­ly think, why did my data­base ac­tion not com­mit. It is be­cause it has not been com­mit­ted to source.

This is be­cause we use Trans­ac­tion­s, a trans­ac­tion is the way to en­sure that y­our da­ta is con­sis­ten­t. It work­s by ei­ther ac­cept­ing the ful­l trans­ac­tion or none of it.

The good thing about a key-chain is that y­ou lose al­l y­our keys at once.

In our code we do it like this:

try (var uow = unitOfWork.begin()) {
    auth = authenticator.authenticate(user, password);
    uow.commit();
}

Mi­gra­tions §2.5

The on­ly con­stan­t in soft­ware de­vel­op­men­t is change. We can there­fore not ex­pec­t our data­base to re­main the same. We there­fore use a Mi­gra­tion sys­tem. It is very sim­ple. We keep a num­bered list of mi­gra­tions in the main/resources/migration fold­er, and a ver­sion in our data­base. If the ver­sion of our data­base is s­mall­er than the lat­est mi­gra­tion, we run al­l new­er mi­gra­tion up­dat­ing the serv­er in the process.

In sum­ma­ry,

• In file X.sql de­scribe how to go from data­base X-1 to X.

• N­ev­er change a mi­gra­tion file, af­ter it has been de­ployed.

• Just cre­ate a new one.

De­pen­den­cies and In­ver­sion §2.6

In the de­sign of the web­page so far, we have used de­pen­den­cy De­pen­den­cy In­jec­tion and in­ver­sion. The idea is to make the in­n­er ob­ject­s de­pend on­ly on the be­hav­ior they need and then have the ex­ter­nal pack­ages de­pend on them!

Test­ing §2.7

It is im­por­tan­t to test y­our code, we d­if­fer­en­ti­ate be­tween t­wo kind­s of test­s.

• U­nit Test­s (On­ly test the be­hav­ior)

• End-­to-End Test­s (Test every­thing)

Test­ing is of­ten done in three stages:

• Arrange (Set­up the s­tate)

• Ac­t (Do some­thing)

• As­sert (Check the s­tate has changed correct­ly)

@Test
@DisplayName("with no local is invalid")
void with_no_domain_is_invalid() {
    var t = assertThrows(InvalidEmail.class, 
      () -> Email.of("my@"));
    assertEquals("domain is empty", t.getMessage());
}

Cover­age §2.8

We test the num­ber of lines or branch­es run by our test­s.

• 100% is im­pos­si­ble, but

• 0% is u­n­ac­cept­able.