"Hacking .NET (C#). An unfriendly territory", Jon McCoy
Jon is the hacker in the .NET community. And hell, he knows what he's talking about! And this was a very overcrowded session. People sat everywhere except on chairs :-)
He must have done this talk a lot of time, because he had a lot of advanced slides and said an awful lot of things, but everything went very smoothly and natural. It was like it was very, very well rehearsed but I think it was just plain experience (and knowing what he talked about).
This was part one of a series of two sessions.
Anyway, check out his site http://www.digitalbodyguard.com/ it has a lot of cool stuff and tools (for free!) when it comes to hacking (and really learning stuff). And he said that the talk wasn't mainly about hacking, but how these "hacking techniques" can be really useful in everyday work as well. He more liked the word "bending stuff" than "breaking stuff".
He talked more about .NET as a concept and not as the framework it is. And that .NET really is an open standard.
Here are som basic tools he used during his talk and that can be downloaded for free.
- Gray Wolf (
decompilereditor) - CompileSharp
- Gray Dragon (attacking an app tool)
He also talked about securing your own computer. Since everything can be broken - bended, sorry - and there is nothing you can do to protect yourself. That's the awful truth. He told us he could brake anything. But his methods of having lots av VM's for different purposes (one dev, one Internet and so on) and then crypto those VM's seemed a lot paranoid and not very pragmatic.
He then also showed some cool IL commands to use when injecting/editing IL code.
Before om demos he talked about the difference between a hacker and an attacker. Hackers mostly have fun. Attackers wants to steal something for own (or others) purposes. Basically they have different motives.
For the demo he had a .NET app that allowed him to load other apps and then he moved a button from one app to another app(!) - and the button still worked exactly the same!! And this was just like 10 lines of code (he said, never showed).
(Part 2) ".NET (C#) Application Code of the Hacker", Jon McCoy
This was the coding part of the "hacking" sessions. Awesome (and very scary!). And just as crowded as the previous talk.
All demos he showed are supposed to be available at http://www.digitalbodyguard.com/. Haven't checked though...
He started by creating and running some low-level assembler code (byte array) in .NET (C#). And since you can do that, you can do anything. If you can load (create) and run assembler with .NET nothing can stop you. Why not load (and modify) that legacy C++ compiled code from -96 and run it in your app the way you want it to work? Cool (and scary).
He then showed a demo where he was able to modify the JIT and then remapped functions, store them and then later put them back. So you can pretty easily take someone else app and make it do other stuff, or stop it from doing stuff - in runtime! If you want to you can also shut another app down (bypassing all exceptions). How? Just inject some endless recursive code. .NET hates endless recursive code and just ignores everything (like exceptions) and shuts down.
He then also showed some cool stuff with reflection. He demoed where he could load another assembly and make the login successful. But really no news there, it's just reflection.
But he showed something way more cooler, he took the same assembly and made all privates public (with the help of Gray Wolf, see previous session). And then he could use the same assembly and use it as an API instead of using reflection. Can actually be very useful! :-) And as a side note. Gray Wolf handles both obfuscated code (deobfuscates it) and also signed assemblies, it's all taking care of. He he he :-)
He then took his computer's biometric software and modified one assembly (with Gray Wolf) and injected some code (IL) where he could show a MessageBox with the admin password.
The only "problem" here is that he knows way more IL than most of us - I mean a lot! He said that he sometimes writes entire apps with just IL(!). And he also knows, deeply, how the CLR works. And he also know a lot about assembler programming. And that is really helpful when it comed to hacking stuff.
But, bottom line is; anything can be broken! And you can't protect yourself against it. You can make it a bit harder, but that is really time consuming, and eventually it will be broken anyway - if somebody wants to.
There where a lot of questions afterwords about if this was true or not, and if there where nothing you can do. The basic answer everytime was: no.
All with the power of .NET.
Long text about this session. Sorry about that, but it was really cool stuff!
"The JavaScript Inferno - A decent into the Client-side MVC Netherworld", Rob Conery
This was a live coding session. And those are always hard to retell. But it was a really good session.
He built an app, side by side, with Knockout, Backbone and Angular. Just to show the differences between them. Really helpful to see. And he wasn't too opinionated as well, he showed both what he thought was good and what was "bad". They all have their pros and cons.
My opinion, after the talk, was that Angular works really well with MVC WebAPI (and node.js) as it has a wrapper (abstraction) above the jQuery ajax (Angular actaully includes a jQuery light version) for doing RESTful programming. That's cool. And Knockout works, probably, a bit better with regular ASP.NET MVC apps as it is used with (if you want to) regular jQuery ajax.
He also emphasized that these frameworks are really good and simple when it comes to doing simple stuff. But when things get complicated, these tools become very compilcated as well.
"Make Impacts, not Software", Gojko Adzic
I love Impact Mapping! And I know a lot about Impact Mapping. I have read the book, I have had internal and external presentations about this. But I just had to listen to Gojko :-)
And how I loved this talk! This talk alone was worth the trip! :-) And it actually made me think about Impact Mapping in a little bit different way as well.
He started by talking about "declaring victory to soon". Victory is not when software is shipped. But we usually tend to see it that way. What does "done" mean? Really!?
He took the Vasa voyage as an example of declaring victory to soon. We have but the ship into the sea. But was that success?
He then talked about "negative metrics". What is that? Well, what doed low test coverage tell you? It tells you something is bad. But what does high test coverage tell you? It might not tell you anything! Negative metrics. Or measuring velocity. Low velocity is bad. But is high velocity good? It may not! It's a negative metric.
Then, the best part, that really struck me: he spoke about almost the same thing as Allan Kelly did on day 1 (see my previous post). Failing fast and survivable and learn from your mistakes. Impact Mapping helps you with that.
If you have a real road map (like Google maps) you can see that you have a lot of other roads you can take if one road is closed or if we missed the turn. And you can do it easily and fast. You want that with your project as well! That's your impact map.
It's like using a GPS. "Where is the next turn? How far away is it?" When do we get there?" And we wont drive all roads to get there, we just want to get to our target as fast as possible.
He then spoke about user stories, and why they often miss the target. Take the following sentence (from a common user story): "In order to monitor inventory". Sounds okay? No! It's not good! Why? Well, doesn't he already monitoring the inventory? Probably. He/she can just go down and check the stock, he/she can read all the papers. The story isn't telling why we should build anything. Instead, write: "In order to monitor inventory faster". Now that is a change! Something must be done faster, then you save money! It becomes useful. And if he/she doesn't do it faster (or even slower) - then stop spending money on this thing! Doing something faster is our next turn (as in the GPS).
And Impact maps helps us create options and visualize assumptions. We can't know in advance if something will succeed (checking inventory faster). And it helps us test an assumption faster and cheaper - by creating options!
Take this example. A manager thinks that his online game will be more successful (more player will play) if you develop Levels & Achievments. That's estimated to about 9 months of work. "Why do you want this feature?" "So players can post their achievments on facebook." "Okay, you think that players posting on facebook will get others to start playing?" "Yes.". Okay, here is the impact map for that.
And it turns out that this didn't lead us to anything. "The road was closed or didn't exist". We didn't get more players. And by creating options (Tournament winner) we could prove that posting stuff on facebook did not lead us to the goal. And we proved it in 6 hours instead of 9 months. Now how about that!
So fail cheap, and fail fast. Impact mapping can help you with that!
Wow, that's a lot of text. But this is a favorite topic for me :-)
"Web usability on a Budget", Tim G Thomas
Usability is a bit of my special interest as well, so I had to listen to some usability session...
Wel, he first started talking about what usability is and isn't.
Words used to describe unusable systems (often by users): "Frustrating", "Intimidating", "Confusing".
Words used to descrine usable systems: "Pleasing", "Inviting", "Clear" (the opposited basically).
Often in large projects (like 30 people working for years) we already have a lot of roles (visual designers, UX designers, UI designers and so on) and design principles But what about small projects and teams (like two developers)? You basically just have one role: developer. But there are some basic design principles you can use.
He showed http://www.zenpen.io/ as a great example of a very simple word editor that really just focus on writing text. Try it out. It is really cool.
He also showed https://www.neonmob.com/ a an example of how poweful it is to use the user's language. Don't call things with technical terms, use the user's language. Say "attachments", not "upload". Don't say "Save" - what is that anyway: "saving something", when do you do that in real life? Perhaps you are "filing" things, then use that word.
He said one little interesting thing. You know all these "Confirm popups", like "Delete? Really!?". Why not, instead have a button which unlocks the delete button? Pretty interesting thought...
Then he listed some things he thought was useful principles:
- Follow conventions
Use logo on the top right, quick menu on the top, search at the top right and so on. - Emphasize and deemphasize
Like in "nudge" the user. He showed https://www.mint.com/ as an example. Use colored buttons to make them "important" (and use the word "free!" - it's a nudge). Also look at the CAPS menu items - they stand out a bit to make them more "important". Cool little tricks. - Use "cool" icons
He actually showed http://manage.windowsazure.com as an example of how icons can be really helpful and remove a lot of "text clutter". Eventually users will recognize symbols. It's like the subway and road signs. - Provide affordance
On the web, we don't have much physical affordance since it's only 2D. Affordance is like: you see a door knob and you know instinctively what to do.
So, on the web you must make things obvious. Make a button look like a button. Also the "hand" cursor is like an affordance.
- http://wireframe.cc/ - Simple wireframing (duh) Example: http://wireframe.cc/example
- http://fontello.com/ - clean icons
- http://dribbble.com/tags/ux - examples of people tagging sites as good UX examples
- https://creativemarket.com/ - design templates
- http://uxdesign.smashingmagazine.com/ - design news and articles
- http://design-seeds.com/ - color schemes
- Last, but not least, buy someone a cup of coffe in a coffe shop and have them sit down with your app and just talk about it!
"Growing software from Examples", Seb Rose
He talked about BDD, ATDD, Spec by Example and what is the difference? Well, same thing different name - he thought :-)
He talked about that examples are useful as documentaiton - living documenation (if you automate it), And he talked about using Relish as a source for keeping those.
He then talked about things to consider when using examples (as specs):
- Ubiquitous language
It's powerful, because you can use it as a documentation everyone understands (at least in the company, or those using the system). - Prefer declarative examples
Focus on behaviours instead. It's easy to write specs that become to technical and to detailed. - Avoid workflow style
Can be detected by that it usually contains lots of steps in the scenario. Like a workflow to get to the "point". Instead, focus on a single behaviour, and isolate it. Example: "When on the checkout page" is enough. It's unimportant how we got there. - Consider costs and benifits
Examples are not always needed for everything. Consider when it has value and not. The more isolated you can test something, the more tests you can write. TDD - lots of tests. End-to-end tests - not so many. It's like a pyramid. - Exercise only as much as needed
Not always end-to-end tests. Try to isolate things. And avoid UI tests if possible. Try to slice the system into testable pieces. If you test the UI, try to isolate that as well - not testing all the way down to the database.
"Rigorous, Professional JavaScript", James Shore
This was mostly a live coding session. So not much to say. We have, at Active Solution, also watched much of this on his online course: http://www.letscodejavascript.com/
This baically was about showing some techniques on how to prepare your code for maintainability over time. In JavaScript (and node).
One cool tool he showed was the web browser test runner Karma: http://karma-runner.github.io You just launch whatever web browser you want to test your code in (and as many as you want) and the tests will be run in that browser. Pretty neat!
Okay, lots of things to say about this day. My head is filled to the brim. But I think it was a really great day. Learned a lot of things. Mostly I liked Gojko's Impact Mapping talk... :-)
No comments:
Post a Comment