One thing that is useful is to get an overview of what a language is about and that is what I have been doing with class time. If you aren't understanding what is said in class, you really need to ask questions about it so that we find a common set of assumptions to move forward with. Asking questions when you don't understand is an important job skill. More than one programmer has been fired because they didn't understand what was going on and didn't want to let anyone know and so didn't ask the questions necessary for them to accomplish their assigned tasks. I haven't fired a student yet -- so speak up and ask questions -- think of it as a safe way to practice an important skill.
That said, since most of today's handins indicated that people weren't very far along with this code, the task list is structured in smaller steps than usuals with some of the steps geared toward how you go about figuring out an existing piece of code. [Haskell style functional programming makes this easier than other systems where there is a lot of local state to manage when you are investigating the code.] Such code is called legacy code ( wikipedia entry) and maintaining and modifying such code is a standard work task. A classic book on this task is Michael Feathers' Working Effectively with Legacy Code. I haven't read it but have read a lot of people's discussions of it. One example of such is the discussion from programmers.stackexchange.com. It references Working Effectively with Legacy Code which was the title of a 12 page white paper Feathers wrote before writing the book. The obligatory youtube link here would be Rocky Mountain Ruby 2011 - Opening Keynote: Code Blindness by: Michael Feathers youtube 31:44 -- talks about what happens when people who don't understand software but need software hire people to make software for them.
If you are worried about what sort of vocabulary you should have been picking up from reading the textbook, most of it can be found in the Chapter titles, Section titles, and Subsection titles listed in the table of contents for the parts of the textbook that we have read.
As noted on today's log file, if the reference page is plain text and printed in 2 column mode landscape front and back, that is 276 lines of text where a line of text is 82 characters long. Split equally between chapters, this leaves us with 23 lines of notes per chapter. For printing, I would be doing the following on a linux box
enscript -2r -p refpage.ps refpage ps2pdf refpage.psand then printing refpage.pdf. This process produces a pdf file that I know I can print (not all pdf files are portable -- often microsoft products and google chrome produce pdf files that won't print on the department large printers).
> ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let fibs = 1 : 1 : [ a + b | (a, b) <- zip fibs (tail fibs) ] Prelude> take 10 fibs [1,1,2,3,5,8,13,21,34,55]Fibonacci values are a list that starts with 1 and 1 and continues summing pairs of values, one from that list and one from the tail of that list (zip pairs up values from two lists; take extracts the first n values from a list).
For people interested in WebGL, there is a 3 hour course on it that looks interesting but I haven't watched yet called: SIGGRAPH University - "An Introduction to WebGL Programming" youtube. The reason this is interesting is that ACM SIGGRAPH is the main computer graphics conference where researchers and people in industry get together each year. From time to time there is some game stuff there, but what I found most interesting was the work on animation and movie special effects. See SIGGRAPH 2015 - Computer Animation Festival Trailer and Amir & Amira (SIGGRAPH 2015 - Jury's Choice Award). For the sort of research in this stuff that is still going on, see the minute and a half video Skin Stretch: Simulating Dynamic Skin Microgeometry SIGGRAPH 2015, and 24 others on the playlist SIGGRAPH 2015 papers that begins with Time-lapse Mining from Internet Photos [SIGGRAPH 2015]. In 1997, there were 48,700 people at the conference, but by 2015 it had shrunk down to 14,800. It has been going on since 1974 and will be in Vancouver in 2018 (see wikipedia entry).
How far this approach to testing can be taken is unclear. There is an interesting discussion of how Selenium works at Selenium Webdriver by Simon Stuart. There the observation is made (3 quotes):
We would be talking about this in the last quarter of the semester, so it would effectively be an alternative to Scheme or Haskell in the current plan. It seems close enough to these languages that it is a plausible alternative. As it first appeared in 2010, it would be the most recent language we would have looked at. In order to have time to get it set up for the fourth quarter, we would probably need to decide on the Tuesday we get back from Reading week, so more on that later. Will keep you all up to date as I find out more.
For those who would like to see something less literary, The PEEL Approach to Paragraph writing in A2 Business (youtube 12 minutes) is presenting a very similar approach without the Shakespeare examples (the L is about linking paragraphs together in an essay, but instead we would want to link to the question the paragraph is answering). Their big picture video The AIM approach to writing the final evaluation Paragraph in BUSS4 (youtube 8 minutes) also brings up some good points.
I show the results of tracing myLength([a,b,c],N) and myLength(List, 3). Note that _ is a name used in prolog when you need a variable, but you don't care about the name because you are not going to reuse it. So x(_,_) will match any two parameters to x with no requirement of their being the same as would be the case with x(A,A) and [_,_] is a construct that would match any two element list.
I then go on to redefine myLength (should have changed name, but this is in the one in the file myABCLength.pl) which requires the elements of the list to be either a, b, or c. We then get a trace of myLength(X,3) and of myLength([b,c,X],3) and of myLength([X], 3). This will be shown in Tuesday's class, but thought I would toss it up now in case anyone is puzzling over this prolog stuff.
As mentioned in the writeup discussion, the easiest way to lose points is to not follow the directions. If you overlook something and don't realize until after you put it in the locker, just run off another copy that has been fixed (as long as it is still on time) and indicate in the day handed in field that it is the `new' version.
The language is probably smaller than Ruby, but we will still just be using a portion of it. I expect we will live in the interpreter and not worry about the compiler. There will be new tasks, but I expect to still be working with the Reuters-related data.
Once there, as noted on the 11th, you will find a tar archive that contains everything called Reuters21578Plus160111.tar (it is 28 megabytes of text files). If you want to transfer it bit by bit (for example because you don't know how to open a tar archive), you would cd into the subdirectory Reuters21578Plus (where I opened the archive on gaul) and then download a copy of everything there.
If this isn't working for you, note that of the first 8 tasks on the Ruby Task List, tasks RubyCopy (1), RubySearch (2), RubyRegularSearch (4), and RubyFreeFormSearch (6) do not use the Reuters data, but instead can be programmed against any text file (for example, a Java or C file that you wrote for a previous programming task). The tasks that have Reuters in their name, like RubyReuterSearch (2), do require the data, but you can still make some progress while you are trying to find out how to transfer the Reuters files.
How to Write a Paragraph on wikiHow also looks good (although a bit longer). One point it makes worth bearing in mind is that the topic sentence should address the question that prompted the writing in the first place. This plays a big role on exams where people will write perfectly fine paragraphs that are about something other than exactly what was asked for.
Getting back to the Natural Language For Programming question, we can take these two explanations of paragraph writing and general notes I had regarding the natural language question from last Thursday and do some paragraph writing as seen in my Writing That Paragraph 01
There are a number of features of rspec that we haven't covered. For example, the usage of before on line 4 of board_spec.rb. The difference between eql on line 18 and == on line 22. The use of context on line 100. The use of be_a on line 109. The usage of should_not equal on line 119. The definition of a helper function like make_marks on line 128 (used all over, like line 95). The difference between the use of before :each on line 4 and before :all on line 101. Who knows what wonders await in the other spec files.
Note, however, that test driven development is different from `testing code'. In TDD, the motivation is to make sure you know what you are trying to do before you do it, whereas testing is about considering all the possible consequences of what you did versus what you were meant to do. Rspec can, of course, be used for either purpose.
export GEM_HOME=~/.gem/ruby/1.9.1 export PATH=$PATH:~/.gem/ruby/1.9.1/binNote these directories already existed on my machine as part of the ruby install. If you are running a more recent version of Ruby, you wouldn't use 1.9.1, but instead your own Ruby version. Having done this, I could then follow the instructions from the Ruby off Rails setup note mentioned above. Note that the person who wrote the Ruby off Rails setup note was a MacPro user rather than a Linux user, so that the instructions work on both systems is encouraging.
For those adding late, last Tuesday we looked at the program: pdf file for above with line numbers (1 column, 4 pages) of the Ruby TicTacToe program discussed on Flying Machine Studios blog entry (source for this example -- Daniel Higginbotham, 10 January 2012). Basically we were looking at what it tells us about how people do stuff in Ruby. At the end of the file are a bunch of notes where I trace through the program and note some stuff about Ruby. After going thru the notes, the groups worked on the question of what was find doing in line 151 -- the idea being that by looking at the program, knowing it is trying to play tic tac toe and looking at the nearby code, one can make reasonable guesses about what find is actually doing.
As a rule of thumb, if 15 minutes has gone by with no code or test cases written, you haven't really been doing project work. Using irb to investigate how some code works counts as coding. Remember, when doing something new, work in small steps and constantly check to make sure things are going the way you expect.
irb irb(main):001:0> -1 | 1 => -1 irb(main):002:0> 1 | -1 => -1 irb(main):003:0> -1 || 1 => -1 irb(main):004:0> 1 || -1 => 1 irb(main):005:0> true || 1 => true irb(main):006:0> false || 1 => 1