The Software Engineering Large Practical exposes students to the problems that arise with the design and implementation of large scale computer systems, and to methods of coping with such problems.
Further details can be obtained by visiting the drps page for the course.
The coursework handout is available here. It is also worth reading through the lecture slides.
More generally this seems to be asking, how you make sure the dependencies you install locally are available for me. Of course if you install them to your DiCE account, they will not be available for me. However, by installing them into your DiCE account, you are demonstrating that they are installable using DiCE.
The requirement is because; what I do not want is for me to attempt to run your web server only to find an error, caused by a missing dependency, which upon further investigation is difficult or impossible to install on DiCE, because you have been developing under Windows/Mac or something else.
What I need from you is a set of instructions on how to install the dependencies and run your web server. You should be able to write these instructions in an executable form (that is, a script). So I should be able to install the dependencies with a single command and run your web server with a single command.
If you want a really concrete requirement then aim for this: "You
should have two scripts in your submission directory, install.sh and
run.sh, I should be able to install and run your web server by simply
executing the following command at the prompt:
$ source install.sh && source run.sh"
If you cannot manage this, then you should ask yourself why not? If you cannot automate installation and execution of your software then you have a very fragile development environment.
Bonus points if you manage to install things to the current directory, so that it does not eat into my home directory space, but that is not a requirement.
There is a bit of tension here, I basically wish for you to develop some "large" piece of software and demonstrate that you are capable of doing this in a maintainable manner, producing sound code with a sound development process. Additionally I'm keen for you all to be engaged with what you are doing rather than uselessly spending your time coding for some made-up need. You could obviously do this whilst developing an app rather than a browser-based front-end. However, in addition, you are supposed to be demonstrating that you can work within the constraints imposed upon you. You are unlikely to be in a situation where you get to develop whatever you want, using whatever technologies you wish. Sometimes the person paying for the software wants what they want and they may even have good reasons for it, even though you are sure you know better.
So upon reflection you can do this, however, in your final report you should justify why you are not creating an HTML5 based app that the user could use both from a web-browser (on any kind of device) and from a mobile device.
In other words treat the creation of a browser-based interface as a specified requirement. Deviation from that should be done if you have a good reason for it. If you have a good reason, to suggest that the requirement is wrong for the particular problem that you are solving then explain why.
You should of course specify this in your proposal. I would not recommend developing an application without a browser-based interface without stating this in your proposal. Of course, the decision to switch from a browser-based interface may come up during development after your proposal has been submitted. In this case you should be able to justify it well, and it would not hurt to ask via email.
Finally, be extra careful to make sure that your app can be run entirely on DiCE (presumably through an emulator).
Yes you can use third-party frameworks/libraries and are encouraged to do so.
The key issue regarding working on DiCE is not that DiCE is some kind of special environment in which I expect you to only use elements that are installed on DiCE. The point is simply that if it works on DiCE then I will be able to evaluate it. Without being able to compile/run your web server I won't be able to evaluate your work effectively. So installing extra things is perfectly fine, provided they can be installed with minimal fuss.
If you simply provide instructions for installing dependencies in the local directory that is fine. Preferably these “instructions” are a script which I can run with a single command (and if not, you might want to ask yourself why that is not possible).
For example, in answer to the specific question posed by a student, Python
is well supported on DiCE and I do not see you having any difficulty with
providing such an install/setup script. So
pip install -r requirements.txt is
fine, that's a single command. I can handle that.
Care has to be taken not to break the University's regulations.
Firstly you cannot submit work that has already been assessed. Secondly, the time aspect is an important aspect of the project, in particular managing the amount of work to be done in the given time.
That being said, the whole reason I wish for you to make your own proposal is so that you are working on something useful (or at least engaging), rather than uselessly implementing some contrived and made-up set of requirements for something that simply isn't needed, only for the purposes of assessment. Whilst implementing something contrived for the purpose of assessment can be useful, I think for the "large" practical it makes sense to allow you to spend your time more productively.
Hence, if you are clear what currently exists and what work you are doing for this project then I'm keen to allow you to continue working on an existing project.
A couple of points: Firstly, you are going to be marked on your development process. The work you have done so far, should not count towards your grade, but equally it should not count against you. So I won't penalise decisions/actions you have taken before the start of this project. However, naturally, distinguishing the two will be tricky. It would help if you detail anything you are not proud of in the report and specify whether you did this prior to the start of the project or not. Additionally, if you have made poor choices prior to now which impede you in making good choices now, tough luck, you accept that possibility when you work on an existing project. I think that is fair. Secondly, if your project is not hosted under git I suggest you do that now, and tag it as “work pre-SELP” or words to that affect.
In this case I also highly recommend submitting a proposal. One danger is that you take work you have already done and then spend some time on “window dressing”. If you do this, I simply won't have enough evidence of merit to award a high grade.
No. Before the early submission deadline you have to choose whether or not you are going to hope for a mark above 90% now, or have an extra week to accumulate more marks up to 90%. The submission marked will be the latest one made before the deadline. Hence if you submit both before and after the early submission deadline, only the last submission will be marked and it will be capped to 90%.
That's a good question. First of all I would suggest coming along to the first lectures of both. You should be able to switch courses up until the end of week one (it's a tad unfortunate that the CSLP will have its first lecture on Friday not leaving much time after that). I should of course also suggest that you speak with your PT, but I'm guessing you already have and they have essentially told you that either is fine.
The two courses do have quite a bit of similarity. In both cases you will be developing some large piece of software (size is relative, we mean large in comparison to the coursework you have done for other individual courses). The difference is what you learn from doing so. The software engineer is concerned with producing a piece of software to satisfy some set of requirements. Often those requirements will not be very well specified and in some cases the correct thing to build will not be known when you start. The focus is on building a piece of software that is fit for purpose and hence can be used by the intended users. The computer scientist on the other hand is likely more interested in finding out some particular fact or facts. They are using the computer to gain insight and hence they may be less concerned with how *others* can use their software provided that their software can answer the questions *they* care about.
Of course in real life, the computer scientist may write more general software. So you may start with a computer program which is capable of, for example, computing your own devised economic model. But you then realise that many other economists could benefit from much of your functionality (suppose it solves a set of differential equations), so you generalise your software a little and you come up with some kind of DSL for inputting the economic model. At this point, you may have some users and you become something closer to the software engineer. Even if your software does not go down this path it is rarely a bad thing to keep your source code well organised and maintainable so that you can update it in the future, if only because you now want to answer a *similar* question to the one before. Additionally you may well have collaborators who either want to use your program or modify your source code.
If I can try to sum up the difference in a short sentence or two, I might try something like this: The SELP is focussed on developing a particular piece of software to fulfil some requirement and as such is more concerned with your development process and the end result. The CSLP is more concerned with using programming skills to investigate some interesting problem or question.
Another attempt might look something like this: The CSLP produces a program that has some desired output from some given input, whereas the SELP has some desired *behaviour*, and this behaviour should be intuitive to the intended user (although that may be another machine).
Just as the computer scientist may turn software engineer, the software engineer may turn computer scientist. The correct behaviour may require the correct computation of some function. For example a smartphone application which acts as a pocket unit-converter must have an intuitive interface, but it must also accurately convert metres into yards, lbs into kilograms etc.
Just as a final note, in theory the Software Engineering Large Practical could be devoted to a project to investigate some aspect of software engineering. However, for this year at least, the course will be centred around applying software engineering principles and practices to the development of some (hopefully interesting) piece of software.
I hope this has not confused more than it has helped but I did not want to simply repeat what you have already read in the DRPS.
This tab will become populated shortly with a list of resources for various plausible languages. I have split this into four sections. The first is those I recommend if you are stuck deciding and have no other reasons to choose a specific language. The second represents the more questionable choices, choose one of these if you have a good reason. The third section does not represent any resources but language I think you should avoid. Ultimately it is your choice, but my advice is to avoid one of these. Finally the fourth section represents rather more esoteric approaches which are generally still in the research phase. A project done in one of these languages would be more one testing out the language/framework. This is still possible, but speak to me first.
As I explained in the lectures, web development frameworks are distinguished along several axes but the most important for you to consider is likely the “weight” of the framework:
Python is a popular programming language that is used to power some of the more popular web sites. Hence its credentials to be used for this project are favourable.
The language is a dynamically, strongly typed language with very good standard library as well as third-party library support.
Ruby is similar to Python, a dynamically, strongly typed language. It has gained much popularity as a web application language. The popular websites github and twitter were built upon Ruby. Twitter have since moved much of their work to Java. People like to generalise, but this was when Twitter was already a global phenomenon. If you think you will outstrip Twitter's traffic as of 2010 then you may consider their arguments, and decide whether Ruby is too slow for you. As a side-issue, this demonstrates well that perhaps language choice is not quite so irreversible anyway.
Ruby on Rails is the flagship web application framework for Ruby (actually the flagship anything for Ruby. It is very well supported, and has many existing application to learn from.
The official tutorials are the best place to get started with Rails. This page gives you something of an overview on getting started and will have you setup with a very simple web application within an hour at most.
If you are keen on Ruby but would rather a more lightweight solution than Ruby on Rails represents, then Rack is a good place to start.
Tutorials for Rack are a little less self-contained. You can start here. However, since the emphasis is on allowing you to do things your own way, most official tutorials are not really self-contained. If you choose Rack, you'll have to do a bit more research yourself.
Java is a strongly, statically typed programming language that most of you will be somewhat familiar with. Java has strong support for web development, places such as Google App Engine have SDKs specifically for Java developers.
In general web application frameworks for Java tend to be on the heavyweight side. Arguably this is more ceremony than you will require for this practical. On the other hand if your proposal relies on a large amount of back-end server work and you are most comfortable in Java, then the additional concepts should not be too burdensome to learn.
Google is a web-company so when they release a web toolkit there is a good chance it is worth evaluating. Google Web toolkit has some amount of installation but after that allows you to have a local running website within minutes.
You should get started here and then follow the tutorial to build a simple stock tracking web site. Unless your project is heavily dependent on much front-end work, this should be enough to have an initial version of your application.
Spark is lightweight web application framework which makes working in Java more akin to Python and Ruby than it might otherwise be. A good question to ask yourself might be, “If I want that, why not just use Python or Ruby?” A perfectly reasonable answer might be that you are very familiar with Java.
The quick start on the homepage provides a four line hello-world web application to get you started. Of course this means that you have to read a bit more of the documentation to actually do anything useful. This is not really arranged as a tutorial, but even still should provide you with enough if you're willing to really understand how every part of your application works.
Jodd is a described as a series of small web development frameworks. What this means is that it consists of a series of interchangeable libraries to perform most of the entire stack of a web application. Importantly, using one, does not force you to use any of the others. In this way it is more versatile than something like GWT.
Although there is a quite a bit of documentation, there is not quite a step-by-step introductory tutorial. That said, there are two example applications, start with this one, but you might also wish to look at this one to see how common tasks are done.
The relationship between C# and Java is much debated. For this project, they can certainly be considered very similar. Both are strongly, statically typed, object-oriented languages with automatic garbage collection. The mono project should allow your code to work on DiCE.
The most obvious place to start with C# is ASP.Net, by going here. This is clearly a heavyweight solution and once you have decided upon C# and ASP.net you will likely do everything “The ASP.net way”. There is plenty of documentation at asp.net. There are a few sub-options having chosen ASP.net that vary quite significantly, these are: Web Pages, Web Forms and MVC. MVC is the most flexible and you can get started by going here.
Haskell is a strongly, statically typed functional language that is both lazy and pure.
Haskell should have the credentials to be an excellent web development language. It is rather loved by academics which in turn means that most of the web application frameworks are also research projects. This means that they in some way (usually via static typic) wish to solve some of the traditional web application development problems, rather than simply enabling you to develop a web application in the traditional manner. For example often the cross-site scripting attack problem is addressed by typing strings as ‘safe’ or ‘unsafe’ depending on where the string has come from and whether it has had code sequences escaped. This is a worthwhile endeavour but not something I think you necessarily need to concern yourself with for this project unless you are particularly keen.
This page lists web application frameworks and does a better job of describing them than I could. Happstack and Yesod are (I believe) the most usable.
O'Caml is a strongly, statically typed functional language which object-oriented features.
Similar to Haskell, O'Caml should have all the pieces to be a pleasant language in which to write web applications, but for some reason there does not seem to be the desire, meaning that mature web application frameworks are a little thin on the ground.
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: firstname.lastname@example.org
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh