Showing posts with label ThatConference. Show all posts
Showing posts with label ThatConference. Show all posts

2012/08/15

That Conference: Git More Done

The final session I attended was presented by Keith Dahlby.

  • Config
    • git help config
    • git config –l
    • You have the system level configs, user configs, and repository level configs
    • git config –e –global (will open up the global config in default text editor)
    • configs are pretty similar to INI files
    • core.editor = <path>
    • diff.renames = false|true|copies
    • difftool.prompt = true|false
    • mergetool.prompt = true|false
    • mergetool.keepBackup = true|false
    • help.autocorrect = 0|N|-1
    • log.date=default|relative|local|iso|rfc short
    • aliasing
  • Named Commits
    • SHA1
      • or the unique initial substring (6 often sufficient)
    • Symbolic references:
      • branch (moves with commits)
      • Tag (remains static)
    • remote references
    • Head = what’s checked out
      • reference to a branch
      • Arbitrary commit (detatched HEAD)
        • on commit, no branch to update
    • ORIG_HEAD = “undo” for big HEAD changes
      • Saved before reset, merge, pull, etc.
    • FETCH_HEAD = last fetched from remote
      • git fetch <url> <branch>
    • MERGE_HEAD = incoming merge heads
    • Relatively naming commits
      • suffixes
        • ~ = parent; ~n = nth-generation grandparent
        • ^=first parent; ^n = nth merge parent
        • 3 commits ago = HEAD~3 = HEAD^^^
        • @{n} = nth prior value for that ref
        • Undo last commit = git reset HEAD@{1}
      • git help revisions
  • Local workflow
    • Ridiculously cheap – use liberally
      • Write SHA to file in refs/heads
    • Branches to clean up
      • git branch – merged
    • Keep Master clean!
    • New topic branch from master
      • git checkout master –b topic
    • Commit more than feels natural
    • git stash
      • Stash away work in progress
      • Typical workflow
        • git stash save “comment…”
        • switch to fix and then switch back
        • git stash pop
      • git stash save –include-untracked
      • git stash list
      • git stash show –p stash@{1}
      • git stash drop stash@{1}
      • git stash branch
    • Temporary Commits
      • Advantage: WIP lives in branch
      • commit, then git reset HEAD~ to go back
    • Reset path in index to match commit:
      • git reset commit  -- <paths>…
    • Unstage:
      • git reset HEAD – stateged-file.txt
    • Reset HEAD reference to commit:
      • git reset [—<mode>] commit
    • Discard previous commit:
      • git reset HEAD~
    • soft reset = move HEAD; don’t reset index/work tree. Essentially an uncommit
    • mixed mode = reset index but not work tree (default). Unstage
    • hard mode = reset index and work tree (discard changes (ignores untracked files); VERY DESTRUCTIVE!!!
    • git add –patch allows for overlapping changes that should be in different commits
      • reformatting
      • refactoring
      • changing functionality
      • Allow for “hunks” (sections of diff) to stage
      • Key operations: y/n, a (all)/d (delete), s (split), e (edit)
      • Also can be done on reset, checkout, and stash save
    • Rewriting History
      • Permanent when pushed
        • Until then, pretend you were perfect
      • git commit –amend (easiest way to change the last commit)
      • alias.cia = commit –amend –C HEAD
        • git cia –a –reset-author
      • git cherry-pick
        • apply changeset(s) elsewhere
          • like to the wrong branch
      • merge vs rebase
        • think of it like shuffling a deck of cards (merging) vs cutting a deck (rebasing)
        • rebasing are a replay of commits
        • rebase –interactive allows for replay with modifications
        • rebase –autosquash … use “fixup! <message>” and git will automatically combine a commit with one awhile ago
        • config rebase.autosquash
  • Fixing “oops”
    • git reflog
      • ls –r .git/logs
        • HEAD, heads, remotes
      • git reflog –all
  • Finding bugs
    • git bisect
      • binary search through a commit space
      • git bisect visualize = view = overview in gitk/log
      • git bisect skip (current version can’t be tested)
      • run my_script = automated bisect
  • http://github.com/dahlbyk/Presentations
  • http://github.com/dahlbyk/posh-git

That Conference: Design for Software: A UX Playbook for Developers

This session was done by Erik Klimczak. I got into it late, and it was standing room only, so I had to jot notes down on my phone. Hopefully these still make sense and there’s not too many typos/autocorrects.

  • James Webb Young quote about ideas
  • Sketch out ideas
  • Sketch early& often to identify edge cases quickly
  • Define patterns, be consistent, reduce steps
  • Storyboarding as a form sketching
  • Drawing app in context of environment will help define usage
  • Tools: sharpie, moleskine, non-photo pencil, neutral gray pen
  • Wireframing to identify interactions, pattern layout, and get stake holder buy in early
  • Good wireframe: content, interaction, layout, hierarchy, functionality
  • Prototyping: whole point is to be wrong
  • Paper prototyping give sense of relative size. Think about things like touch screens and apps.
  • Prototyping is about taking it. Be clever, not complicated
  • Colors: start with solids and add gradients if necessary
  • Be aware of the psychology of colors
  • Use tints of color to add more colors to your palette of 2-3 colors
  • Shades of gray for the chrome of the app
  • Typography: if done right, you don't see it.
  • For print use serif body font with san-serif headers. Generally opposite for digital
  • Pick a typography and stick with it.
  • Rhythm & Scale calculator in Chrome app store
  • Pick a single family with lots of variations to give variety.
  • Visual Communication: telling the most with the least amount on a screen at a time.
  • Basically logically organizing UI.
  • If things look the same or are grouped together, the user expects them to behave the same.
  • Consistent margins, spacing, type size...
  • Reducing colors, and redundancy will greatly help.
  • Grids actually help break up a UI to help with consistent layout
  • Motion: easing should be between 250-350 milliseconds to always feel snappy
  • Animations don't always have to be complete for a user's mind to fill in the blanks.
  • Use motion for long running operations
  • Artefact Animator for C#/XAML
  • Interaction design: user flow is when the interface gets out of the way so the user feels productive
  • Avoid modal states & pop ups
  • Use color cues (red X)
  • Don't block UI
  • Read About Face 3
  • Solicit feedback: if the user doesn't know they can do something or doesn't feel confident about an action, they won't perform the action
  • Mouse adorners, touch/click states, audio, inline feedback (invalid input, password strength), wizards, refresh animations for long operations all are great forms of feedback
  • UX patterns: don't reinvent the wheel
  • Most every pattern you'd need is out there
  • He has a forth-coming book: Design For Software

That Conference: Erlang Goes to Camp!

This session was presented by Bryan Hunter. I figured it’d be interesting to learn more about functional programming in general and how it can interact with .NET more.

  • It’s a functional language
  • Grew out of Prolog
  • Erlang is great at pattern matching
  • OTP (Open Telecom Platform) has libraries, practices and styles)
  • ERTS (Erlang Run-Time System) is more like an OS rather than a VM running on an OS
  • Erlang is open, proven and cross-platform. It simplifies writing reliable, concurrent, distributed systems. Its pattern matching is FTW.
  • On Github
  • Compiled on any platform will run on any other platform
  • Erlang community is more in the Mac & Linux world, but runs great on Windows
  • Erlang supports concurrency very well; especially compared to other languages
  • Concurrency is hard because of sharing state.
  • .NET 4.0 thread allocates 1MB…Erlang Process (Thread) allocates 1KB
  • Distribution was built-in from the start because every process is isolated and everything is done via message passing
  • One Erlang process can essentially watch another process, even on another machine
  • It’s possible to have a true cluster in that there is no master process/node
  • Editing erlang
    • The shell
    • Text editor + command line + shell
  • Every erlang statement is terminated by a period
  • Every variable is upper case
  • Every “atom” is lower case (like function or key word)
  • Lists are defined with []; like L=[100, 200, 5000].
  • Tuples are {}, like Person = {100, “Joe”}.
  • When a node pings another node, it essentially gossips the known nodes to the new one. As soon as nodes know about each other (and the cookies match), there’s full trust to do anything.

2012/08/14

That Conference: Testing Code From The Pit Of Despair

This session was presented by Phil Japikse.

  • http://www.telerik.com/zerotoagile for a podcast
  • Legacy Code == any code not under test, has a high technical debt, is icky
  • If the code is working and nobody asks you to change it, why change it?
  • Why change code
    • Killing bugs
    • Adding Features
    • Optimize Resources
    • Removing FUD
  • Make one change at a time
    • Fix or add just one thing
    • Test after every change
    • Commit after every passing test
  • Tools of the trade
    • TDD
      • Building up of the Lego blocks of code
      • Inside-out building
    • BDD
      • Don’t start with individual pieces to build the whole
      • Outside-in building
    • Mocking
      • Fakes, Stubs, and Mocks
      • Fakes have working implementations. They’re Hardcoded, not suitable for production
      • Stubs provide canned answers
      • Mocks are pre-programmed with expectations. Essentially creating a specification. They also record behavior
    • Dependency Inversion
    • UI Testing
      • Typically Manual
      • Often tested by customers
      • Tools becoming better
  • Testing and Refactoring
    • Be save; if you don’t touch the code it won’t break
    • Safety Blanket: Integration tests
    • Code Isolation and Refactoring
      • find a change point
        • Finding the point that breaks
      • create a seam
        • the weakest link of the system/class/method
        • use Dependency Injection
        • use commercial mocking
      • add a new test
        • Use test-eventually style
      • refactor
        • Extract Methods
        • Reduce Complexity
        • DRY
        • SOLID
      • Make sure you’re actually isolated
        • Continue to drill down
        • If code is self documenting, we don’t need as many code comments
      • Fix the target issue
        • Code is isolated, tests are in place, switch to T/BDD
        • It’s turtles all the way down
  • Test/Behavior Driven Development
    • Write a failing test
    • Make the test pass
    • Refactor: Remove magic code; add use cases

That Conference: Managing the .NET Compiler

This session was presented by Jason Bock

  • Talking about Project Roslyn
  • The compiler (csc or vbc) is simply a black box
  • There are 44 switches you can throw at csc!
  • Microsoft wants to stop all the re-implementations of the parsers, thus what Roslyn is meant to be
  • CTP == Could Trash PC
  • Only support for C# & VB initially
  • Can be used for things similar to StyleCop like enforcing consistency.
  • Can be used for a deep understanding of Code
    • Like a WCF Operation Contract that is one way, but is returning a value
    • Can provide quick fixes based on the analysis
  • No time schedule for release

That Conference: Truth and Myth in Software Development

This session was present by Leon Gershing (aka Ruby Buddha). The subtitle is “Truth, Myth and Reality.”

  • Git Immersion and Ruby Koans
  • “Do as I say or…”
    • You’re inferior
    • Your priorities are off
    • You can’t be successful
    • You are worthless
    • You’re not a developer
  • A different way of looking at the world is actually a good thing, stop being negative about it
  • Don’t be so dogmatic about something, it just takes practice.
  • Testing, like everything else, is a tool to help you get better at what you do
  • It’s okay to listen to dogma, but don’t just accept it at face value. Always evaluate the information.
  • Everyone must find their own path; their own subjective reality
  • Myth: that which preceded you is invalid.
    • Reality: waterfall is dead. Long live Agile!
    • Agile is Dead…in the same way that punk is dead
  • Agile manifesto was written by 10 hippies…
  • Perception is Reality
  • Where are you heading?
    • Only you can decide where you want to go
    • No one can tell you the answer except yourself
    • Changing your mind about your current path doesn’t bind you to that path, it changes the direction of the path
  • Find forced mentors
    • people that inspire you on any level
    • Have lots of them
    • remember that celebrity is just being popular, not that you want to be just like him
    • Seek out wisdom from all places; from people and locations of all ages and locations
  • Wisdom, like mustaches and mullets, can’t be given. They must be earned.
  • read the poem “The Perfect High” by Shel Silverstein
  • Pro-tips:
    • Read more code than you write, not books or anything else, just read code
    • Write code, and then write it again, then delete it, then write it again, then delete it, then write it again, then…
    • Play with others. There is a big difference between knowledge and wisdom.
    • Trust your instincts.
    • Think AND Feel. It lets you understand everything and have some empathy
    • Enjoy now.
    • Don’t rely on your own excuses (I don’t have the time).

That Conference: Vim–An Introduction for Visual Studio Developers

Presented by Michael Eaton. I attended this session mainly because I’ve realized how much I rely on the mouse lately and how much it slows me down. I enjoy working on my Lenovo ThinkPad because it has the little mouse stub in the keyboard so my hands never have to travel far from the keyboard, but it still takes time to navigate using the cursor just to navigate around. Not only is that slow, but it’s been killing the index finger to fly across a screen.

  • Everything comes down to “My <insert topic here> is better than yours!”. It really just comes down to “Use what you want to use”
  • Vim is definitely far better for touch typist rather than the hunt-and-peck typists.
  • Vim is designed to be really close to the home row.
  • Vim written by Bram Moolenaar and others.
  • vim/gvim/vsVim/viEmu
  • Command mode, insert mode, visual mode, execute mode
  • [i] to go into Insert Mode
  • [Esc] to go back into Command Mode
  • in CM, [Shift]+[A] to go into the end of a line and goes into insert mode
  • Basically look for a Vim tutorial
  • vim is a pure command line editor
  • gvim is the graphical vim editor so it’s slightly friendlier GUI version of vim
  • http://github.com/alanstevens/KickassVim
  • http://vim.org
  • http://pragprog.com/book/dnvim/practical-vim

2012/08/13

That Conference: Designers? We Don’t Need No Stinkin’ Designers!

This session was presented by Jon von Gillern. Admits much of the presentation is based on Mark Miller’s good UX presentation.

  • Wrote Nitriq and Atomiq
  • Why focus on UI?
    • Happy customers == more money
    • Good UI is taken for granted, bad UI is easier to notice
    • Pour UI adds up
  • How can we measure UI
    • Keystrokes
    • Mouse Travel distance
    • Gaze Shift (eye travel distance)
    • Recall Rules of interaction
    • Find signal among noise (don’t make the user think about what they’re looking for)
    • Variance from user mental model (does the UI behave how they expect it to?)
    • Mental Time = Total Time – Physical Time
  • Mental Costs – things that prevent users from getting into the “flow” of being productive
    • Lose of focus
  • Good UI is:
    • Clear (in purpose)
    • Concise
    • Consistent
  • Tools for UI
    • Contrast
      • visual difference between two elements
      • “Visual Weight should match information relevance” – Mark Miller
      • Eyes are attracted to greatest contrast (similar to why young kid’s shows are generally primary colors because they are so different)
      • Nitriq example: Actions have more contract, Information has less contrast
      • Google “WCAG 2.0”
        • Relative Luminance
        • Contrast Ratio
      • Black Text vs White Text article
        • Green, Red, Blue for the order that the eye can tell differences in shades.
      • Testing Tools
    • Color
      • Can represent differences
      • Lots of color == Lots of noise
      • Work with a limited color palatte
      • Hue, Saturation, Luminesces vs Hue, Saturation, Value
      • Pick a hue for a color, and add others by changing the saturation & value
      • Kuler
      • Read the article on Wikipedia
      • ~5% of humans have some form of color deficiency
      • Use Red & Blue, not Red & Green to account for color blindness
    • Size
      • Easier to find large items
      • Important information should be larger
      • Relationship to precision
        • Common actions should be larger
      • Test on the worst device to allow for finding if sizes still work.
    • Ordering
      • You can scan up & down faster than left-to-right
    • Motion
      • Effective for helping guide gaze
      • great for entrance & exits
      • use acceleration/deceleration (easing)
      • Fade in with size at the same time to affect flow documents
    • Shape
      • Icons are a kind of shape
      • Depend on context (flow chart, etc)
    • Fonts
      • Sans-serif: quick to read/recognize
      • Serif
        • better for long chunks of text
        • Character by character legibility (“1” vs “l” vs “I”)
      • Dyslexia
        • Kerning, Symmetry
        • Comic Sans actually helps with this…or just buy a specialized font
    • Parallel vs Serial
      • Don’t display information in serial if it can be done in parallel
        • Modal Dialogs
        • Combo Boxes when seeing all options
    • Shadow/Glow
      • Can help differentiate UI that “sits on top” of other UI
      • Glow can help defuse similar colors that sit on top of other items
    • Gradient
      • Transferring gaze
    • Proximity
      • Similar data should be close
      • Similar actions should be close
      • Vice Versa
      • Bad proximity causes gaze shifting
    • Interaction Patterns
      • http://quince.infragistics.com
      • Remember Parallel vs Serial
      • Just because a pattern doesn’t mean it’s good
      • Immediate, continuous feedback
        • Progress Indicators
        • Preview Hinting
    • Know your users (who, how many, how often)
      • Discoverability
      • How often specific features used
      • gather telemetry
      • Don’t be afraid to steal ideas
    • UI Checklist:
      • What are the 3 most important screens
      • What are the 3 most important pieces of data
      • What are the most important actions
      • Are you using the same terms as your users

That Conference: Roughing It: .NET development from the command line

This session is presented by Jon Polfer.

  • In the beginning was the Command Line
  • Programming is about using words, why not use them as the primary way to interact with the computer
  • Vi/Vim for Unix; VsVim for Vi bindings in Visual Studio; Vi-Emu plays nicer with ReSharper
  • Graphical Vi-Vim Cheat Sheet
  • Using MSBuild
  • CScope
    • Have to create a cscope.files file to tell CScope what files/paths to look into
    • CScope –b –q for building the index only and quietly
  • http://db.tt/PQ2HWqjk for all the code, examples, & slides

That Conference: How to Rapid Prototype Like A Boss

The next several postings are likely to be brain dumps from sessions I attend at That Conference, so they may not make a ton of sense to those who didn’t attend. But then again, why didn’t you go? It’s being held at a water park in Wisconsin Dells in the summer so you can bring your family along with.

This session was presented by Matthew Carver.

  • Author of forthcoming book “The Responsive Web”
  • Wireframes
    • Can be truly rough hand drawings or digital layouts that are still cheap to produce
    • Until a line of code is written, everything is just theory
    • Wireframes can become a “Comp”: Comprehensive Layout
  • Comps
    • Comps are simply a snapshot of the UI, but they lack the full interactions and responsiveness
    • They’re too rigid
  • Why Prototype
    • Fill in the gaps
    • Can anticipate actual scope of the project
    • Offer site/content managers to start testing out ideas before any actual code is written
  • Tools
    • Foundation 3 by Zurb
      • Uses SASS
    • Bootstrap by Twitter
      • Uses LESS
      • Not built specifically for prototyping
    • HAML
      • Specifically for Rails, but makes for quick view development
    • SASS
      • A CSS3 extension
  • Basics of Prototyping
    • Reach conclusions from the wireframing
    • Placeholder images: placehold.it/300x300 == a 300 x 300 image
    • Foundation had a number of build in button style, which gets more into the art direction instead of just prototyping
    • Visibility classes for different browsers/sizes