This is a technical blog entry of what I've learnt during the day. So if you don't have a computing background you might not understand all of it. That or you might find it rather head spinning.
9am Had a coffee before I started. First session of the day was "Thinking in Functional Style using F# and (some) C#" by Venkat Subramaniam. He gave a session on Design Patterns the day before, and that was good so I thought I'll give this one a go too. I actually own one of his books, "Practises of an Agile developer". Should have gotten his autograph but I forgot. He started off by talking about what it means to have a functional language, and whether this means other languages are dysfunctional. He talked about the paper that Dijkstra published, that using goto is evil. He talked about immutability, and that it's about transformation of state. OOP was created in 1967, and made popular by C++, and took 23 years to be popular. Functional programming has existed for 50+ years, and it's not popular (yet). But this might change, he talked about how running multithreads on a single processor was like multi processing. And shared mutability causes problems, that it's the devil's work. You have to ensure that your X number of threads do not collide, and even providing locks does not necessarily mean your code is correct. Most concurrent applications are broken. He said pure functions do not modify state, and mathematicians and those who love correctness of code, love functional programming. A pure functional language does not modify state after creation, but F# is not pure.
Venkat Subramaniam.
What his session covered.
Variables are bounded once created. The second assignment (=) is really just a boolean operation, so temperature is still 25.
From the slide above, you can use the
mutable keyword to change temperature. So you can do the following.
let mutable temperature = 25
printfn %d, temperature
temperature <- 15
printfn %d, temperature // Temperature now 15
He talked about higher order functions, functions which call other functions, and allow composition using functions. And how purity allows easier reordering of functions at will, since there is no state order to maintain. He talked about how a function has a name, body, return type, and a parameter list.
e.g.
List<int> num = new List<int>() { 1,2,3 };
num.ForEach((e) => Console.Write(e));
(e) is the param list
Console.Write(e) is the body
the function name is an anonymous function whose return type is inferred. And this makes
ForEach a higher order function.
ForEach becomes an internal iterator, it is better and more concise. It's better than using a for loop which is like a lazy dog. :)
Again he talked about idioms, and programming is not about syntax, but about idioms. He relates this to idioms in society. e.g. one way to do a for loop in F# is.
let numbers = [1..6]
for e in numbers do
printf "%d", e
printfn ""
The idiomatic way to do this is
List.iter(fun e -> printf "%d" e) numbers
or
List.iter(printf "%d") numbers // more consise
Functional programming would be nice if there is garbage collection. He also mentioned that think of functional programming as state transformation and not state mutation.
Here's an example of imperative style in C#
List<int> x = { 1,2,3 };
var doubled = x.Select((e) => e * 2);
... // then foreach
and functional style in F#
let x = [1..6];
printfn "%0" (List.map (fun e -> e *2) numbers) // prints 2..4..6.. 12
printfn "%0" numbers // 1...6 i.e. immutable
He ended with an example as follows to show the highest stock price among selected stocks below the price of $500.
10:20am Next session was "HTML5 and CSS" by Chris Mills from Opera. His slides will be available at slideshare.net/chrisdavidmills. He talks about how tech tech undergo a honeymoon period. And then they sort of flatten off. So do you need it? Browsers currently have specific implementations for CSS and so you need to use these prefixes. e.g.
background: -webkit-linear-gradient
background: -moz-linear-gradient
background: -ms-linear-gradient
...
And it's important to have graceful degradation. He said to build a base that works, and works better in modern browsers. To use media queries for different content depending on the resolution, and to use web fonts. Sometimes graceful degradation doesn't work, and if that's the case to use a fallback mechanism e.g. flash fallback for the video tag. Or you could use modernizer to take care of it. He also mentioned IE conditional includes of CSS are useful. These are ignored if not required. Other websites which he mentioned are css3pie.com and selectivizr.com.
I had an early lunch which was Chicken Tiki Masala again. And took some oranges. And a smoothie.
11:40am The session before lunch was "How to Destroy the Web" by Bruce Lawson. A bit of tongue-in-cheek session. He started off with talking about his daughter saying it was bad to bomb Iran and he wanted to go to the web to show her that Iran was just full of evil people, instead he found this.
Nice Iranian Girl website, fancy that, really I thought they were all evil!
He said that everything leaks out on the web, and therefore you should only let people with the right browsers in. E.g. restrict people to websites, and force them to use it.
Bruce Lawson.
One way to force people to use only certain browsers, is to look at user agent strings and block them if they use these. :D
Nuff said..
Another way to destroy the web, is to only allow users with the right devices in, e.g. iPad only websites. Great idea. More people in india have phones than access to flushing toilets. So restrict third world countries by making them iPad only! Muhahahaha... another way to destroy the web, require plugins. For example, the South Korean government requires all banking and ecommerce transactions must use ActiveX on Microsoft Explorer. Or write something that require Native Client, by Google. Making the web country specific is another great idea on how to break the web. He refers to youtube.com as kittens on skateboards. And showed some opera data that presented the conclusion that people across many countries want to visit the same sites but consume these sites on different devices.
He talked about how the #! hasbang technique broke the URL addressing system, good work guys. And how the NYSE euronet website has a pretty good example on how to break the web by providing a really stupid user agreement that nobody reads. :) You can also require specific types of hardware, e.g. need a mouse, so you can force disabled people to not use the web because it would be too hard for them. He showed examples like the "Create a filter" link in Gmail was created using a span, which does nothing for a screen reader. Or use empty
body tags in HTML and have all content created by javascript. :) Censoring the web, but only at the government level works, i.e. the S
cunthorpe problem, if you search for
clitheroe, ligh
twater,
penistone, well it's hard to get results for these words for some reason!!
Ended with a message, that we must "destroy the village to save the village" and the WWW stands for "wealthy western web". ;)
After the session I mostly wandered about and read news on my iPad. And while walking around I caught this on the wall.
Paul McCartney and Elton John, combined tickets sold 32,530.
At some point during the day they called out prize winners, I stayed around for a few minutes but didn't win anything, boo hoo. I did take oranges though. And a smoothie. Don't remember if I took a coffee, I might have...
1:40pm "Async Part 1 - new feature in Visual Studio 2011 for responsive programming" by Lucian Wischik. He mentioned how he worked 2 years on Async, and showed a demo with the spinning toilet bowl of death in Windows 7. :D Windows 8 doesn't have the spinning toilet bowl. Async was created to help with UI responsiveness.
He showed some code that looked like this
async void Button1_Click() {
await LoadSettingsAsync(); // kicks off download. Task remembers where it left off, and some stage, packet arrives, message pump finds Task and finishes LoadSettingsAsync method
UpdateView();
}
async Task LoadSettingsAsync() { // Async method use Async suffix
await IO.Network.DownloadAsync(path);
}
Left side UI thread, right side IOCP thread.
I don't fully understand it yet. But it's something about the message pump, that the UI message pump is key to async. Await always resumes back on where it's called from. Async and await do not create threads. Task is important too. For example
Task<string> // means I will at some time in the future return something of string
"Expert C#" book that he recommended to read. And the take home message was that "Asynchrony and concurrency to not need multiple threads" and all "Async library code should return Tasks and take cancellation tokens". Everything should be up on blogs.msdn.com/lucian in a week.
Had a coffee before I started the next session.
3pm "Async Part 2 - deep dive into the new language feature of VB/C#" continues from the previous session. I didn't have much notes written down during this session as it was a lot of code which I didn't fully understand. Refer to blogs.msdn.com/lucian in a week.
Had some salad and corn before the last session. And some oranges.
4:20pm Last session of the day was "Caring about Code Quality" by Venkat Subramaniam. This one good too, and all in all, I attended a total of 3 of his 4 sessions conducted over NDC. This talk had more slides and pretty much zero code. Here's what he talked about.
- You can't be agile if your code sucks.
- Programs are for people to read, incidentally for machines to execute. (Abelsson and Sussman)
- Fixing problems are 100x more expensive than during requirements phase.
Managers take note :P
- Peer reviews catch 60% of defects. But "priesthood" reviews are useless, people who review code should be people who write the code. Don't get some architect who writes no code or works on a different project to review someone who works on a different project.
- Disciplined personal practises can reduce defect introduction rates by up to 75%.
- Nobody cares about standup meetings. Ironically most companies practise this, he termed this agile by convenience. ;)
- Building high dependability software costs 50% more per source instruction.
- Find a champion for quality in a project, and set a 3, 6, 9 month period on measuring and improving quality for the project.
- Companies never have time to do it but have time to redo it.
- Pay your technical debt, this will hamper progress if left undone for a long time. It's just like credit card debt left unpiled that will just kill you in the end.
- Code must be readable, that means someone else must be able to read it, not just you.
- Never leave programmers in isolation.
- Learn by reading good code.
- Keep it simple!
You know which road companies often take.... :P
- Write tests with high coverage.
- Run tests before checkin, and checkin frequently. It's okay to check in stuff that does not work. Never get merge hell! Always give it. :)
- Learn your programming language, i.e. the one you use.
- Programming is a team effort and requires collective ownership.
- Promote positive interactions in a team, tell people how it could be better not how bad it is.
- Provide constructive feedback and constant code reviews in a team.
- Everybody's code needs to be reviewed, rotate reviewer for each review. "Code review makes me a Hero or makes me Smarter."
- Treat code coverage as cholesterol levels. For example the Guantanamo tool will delete all lines of code without tests. Sounds bloody excellent!!
- Keep things small, i.e. cyclomatic complexity should be small.
- Methods should just do one thing, one level of abstraction.
- Use simian to detect duplicate code (however remember duplicate code for different roles is okay, as according to Robert C Martin)
- C.R.A.P metric (look it up)
- Don't reply on JDD, Jesus Driven Development, Hope, and all that sort of thing which crappy companies practise.
- Risk table!
Complexity Low -> Automated Tests Low -> Risk High
Complexity Low -> Automated Tests High -> Risk Low
Complexity High -> Automated Tests Low -> Risk High
Complexity High -> Automated Tests High -> Risk Medium
- Code smells are somethings that are not right in the code, that make you feel dirty, you can't understand it, it's hard to explain and it does some magic.
- William Zinsser "On Writing Well" book recommendation.
- Don't be clever, be clear.
- Comments should explain why it exists, i.e. you should never have to explain a joke just like a comment.
- Make it easy to look at errors!
And that's it. He provided a summary as well but that's pretty much all I've written above. I took more oranges before leaving. To conclude, today's the last day of NDC and
5:20pm was the time I left. There will be an NDC 2012 video torrent available sometime soon on the NDC website. It's back to the office on Monday. Today was the work summer party as well but I'm tired so I didn't go, opt for the lazy way out and go home instead. Oh and the nationwide strike ended yesterday, June 7th. The workers ended up not getting anything. That's really too bad for them but they should consider themselves fortunate that they're not Greek right now. Or that Norway's not using the Euro.
Update: NDC 2012 videos are now available on
vimeo. You can thank me by posting a comment. ;)
