r61sbSyP

1Hello All,
2
3It took many 12 hour days of marking, and it broke my wireless mouse but by now you should be aware that the marks for the ACW have been released.
4
5If you visit your submission on Canvas you should see both the rubric, breaking down the marks that you got for each section, and a comment with additional feedback, highlighting where you may have missed any marks.
6
7General ACW feedback:
8In general the group did a good job of sticking to the specification. You should take note of any areas where you did not meet the specification because you had not read it thoroughly or not asked a question when you were unsure. If you are given a specification in the workplace it is absolutely key that you are able to follow it. This helps to prevent wasted time later, when you need to go back to your designs/plans and change work you have already done. It is also very good practice to write your tests before you write your code. It was very clear where a student had thoroughly tested their work with Postman and by checking it against the test server. If you have these resources available to you it can make your time far more valuable, as you spend less time making mistakes. You will have probably heard many sayings along the lines of work time is 60% designing and testing, 30% writing code and 10% documentation - don't forget to factor this in.
9There were a few common or recurring issues around database migrations. If you try to create manual migrations AND rely on automatic migrations then you can leave your code in a state where Entity Framework doesn't know which is right and therefore will not create your database(s). Normally manual migrations are better because you get manual control over rollbacks, etc. but you need to keep them up to date.
10There were also some recurring misunderstandings around signing - the signing process hashes your data for you, so hashing before signing is not necessary.
11Finally, note the immense importance of APIs being resilient. You are opening up access to your code to the internet. With a RESTful API you have little in the way of a contract so many users could interact with your API in a way that you didn't expect (accidentally or maliciously) - it is extremely important that you manage error events and give back useful feedback where errors do occur, throwing and returning an exception is rarely a good idea.
12
13Exams:
14
15Congratulations to everyone who has now finished up all their exams. The exam for this module has an average mark of over 60% which is a good sign (although marks have not yet been agreed at the module board).
16
17General feedback on the exam:
18Most students seemed to do better in Q2 than Q1. Q1 involved more real-life situations like the type of situation you may well find yourself in soon, so be aware of how to apply your knowledge, not just parrot back information.
19Q1: There were some questionable layered models so you may want to revisit the difference between layers and tiers, and consider the value of layering your software applications for high abstraction. RPC caught a few out - especially as REST could be considered a type of RPC. Generally though, RPC involves more concrete contracts and results in more strongly coupled applications. When it came to saving GPS positional data to the database only one at a time, many reasoned that this may be because the service was not multithreaded. This is reasonable but would cause more issues than just not saving to the database. Many were not able to come up with a well-rounded technique to solve this issue above "make it multithreaded". Another consideration would have been that perhaps the application was locking and the lock scope was too large or the locks were unnecessary - something like optimistic concurrency control would have solved this problem.
20Q2: There were a few misunderstandings over mesh networks. Be careful not to describe this type of network as 'decentralised' as this is a separate topology in its own right; more accurately mesh networks are 'fully distributed'. Many mistook message buses for enterprise service buses or the heart of a SOA. A message bus does decouple the sender and the receiver but only by providing a single messaging channel. Applications listen for messages on the bus and take those which are meant for them. The bus doesn't do any translation, but this can be managed by adapters, allowing different applications to speak to one another if the correct adapters are put in place in the pipeline between the bus and the application. Some examinees were unsure about the role of edge computing in bringing low-power computation closer to the data source/consumer to speed up the transaction time. The pattern allowing these edge servers to communicate together through the (more powerful, slightly higher latency) fog, and the eventual ability for the fog servers to communicate through, and send all relevant data to, the (very powerful, high latency) cloud was missing from some answers.
21
22Marks for exams need to go through moderation and module boards. As per university policy these marks will be released on the University exam results day (on http://my.hull.ac.ukLinks to an external site.)
23
24I hope that general feedback was useful.
25
26Good luck to you all in your coming adventures. Keep in touch.
27
28Kind Regards,
29John