Real World Coding
[outline]
In this part we'll look at real world coding. We'll look at some of the ways in which we think about drawing together coding projects, and some of the current wider and upcoming issues in coding culture. We'll then wrap up by covering some of the elements of Python we haven't looked at in detail but which it is worth exploring on your own.
Structuring code (powerpoint)
Further info:
Treading in Python is generally managed by the threading library. A good starting tutorial can be found on the Python wiki, which also has more detailed information on the GIL.
You can find out more on interacting with other programs in the subprocess library documentation.
A good starting point for Python design patterns is Andrei Boyanov's post "Python Design Patterns: For Sleek And Fashionable Code" which gives a realistic overview of which patterns are needed in Python
Further info:
For more on patterns, see this list: Software Design Patterns.
For info on their evil twins, anti-patterns, see: Anti-patterns (caveat lector, some of these we'd put in the 'good' category, so there's considerable controversy around some).
Types of test:
Unit Tests
Stress testing
Alpha/Beta releases
Usability
Regression testing
Software testing
Unit Testing is a major part of the design philosophy called Design by Contract, which concentrates on loose but well defined coupling.
Quiz:
When developing code using test driven development you should _____________________________________.
- write your code and then test it to make sure it works
- write your tests to cover as many eventualities as possible and then write your code to satisfy these conditions
- write your code and tests in parallel so that you can adapt your tests to fit the situation as it evolves
- adjust your tests to make sure that they all pass
Correct! The idea is that tests structure the writing of the code, not the other way around. If the tests correctly match your specification of the interactions between classes, you shouldn't need to adjust them at all.
Having looked at how we structure code, let's look at how we structure projects to build code, along with the life-path of software.
Software Development (powerpoint)
Further info:
You can find out more about specific development processes/process elements at the following links (full list):
The Waterfall Process
Iterative development
Extreme Programming
Rational Unified Process
Release early, release often (RERO)
Continuous Integration
Scrum
Kanban
Sprints
Pair programming
The starting point for getting your software professionally packaged is the packaging pages. For more complicated projects there's also setuptools, which works with the distribution library (see also).
On compiling for specific operating systems, see the tutorial and FAQ.
If you want to internationalise your code, and you should, The starting point for this is the gettext library and locale.
For 'Open' licenses, see the Open Source Initiative and Creative Commons.
For an insight into the day-to-day lives of real coders, see:
Higgins, A. (2007) 'Code talk' in soft work. Ethnography 8(4), pp.467-484.
Given this course attempts to give an overview of the software industry, it would be remiss not to cover some of the issues the industry is currently trying to address.
Industry Issues (powerpoint)
Further info:
There's a good site on the gender disparity in computing on Wikipedia. See also, for the UK, this article from Computer World.
The chief formal organisation for women in computing in the UK is the BCSWomen Specialist Group (info) of the British Computer Society. But CodeFirst:Girls are always looking for trainers.
On the environmental impact of computing, see the Dirty Bits project blog of Nathan Ensmenger (Indiana University).
Greenpeace release a series on computing every couple of years, called Click Clean, and have worked closely with major companies in the push for renewable energy use. On the industry side, the main body is The Green Grid. A good general article is Burrington (2015).
Quiz:
In 1942, author Isaac Asimov introduced the "Three Laws of Robotics" to the world. These were:
1) A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2) A robot must obey the orders given to it by human beings, except where such orders would conflict with the First Law.
3) __________________________________________________.
- On hearing the phrase Domo Arigato, Mr Roboto, all robots must respond with "Domo. Domo."
- A robot must protect its own existence as long as such protection does not conflict with the First or Second Law
- A robot must know it is a robot
- A robot can only pop some moves on their own time
Correct! The "Three Laws of Robotics" are a classic example of early thinking about the relationships between people and computers, and have, therefore, had a suprisingly large influence on computational ethics, at least informally. The correct response to "Domo Arigato, Mr Roboto" is, of course, "Dou itashimashite". "A robot must know it is a robot" is Kesarovski's Fifth Law of Robotics. Robots, strangely, can't do robotic dancing half as well as humans: see? Far too fluid. Rubbish.
So, that's it for the course. The last slides look at stuff we haven't covered in the course, and concludes with some sources of extra information and advice.
Wrap-up (powerpoint)
Further info:
More on type annotations can be found in PEP 0484.
Efficiency tips can be found in the FAQ and Python Wiki.
To convert Python 2 to Python 3 automatically, see the 2to3 library.
If you need a particular python version or library, use a virtual environment or Conda (info; info).
Quiz:
Finally, fix this code to finish!
class HelloWorld () _____
def hi(self) :
print("Hello World!")
HelloWorld.hi()
;^:);^)
Hello You!