piątek, 2 sierpnia 2013

Programming tech talks

  1. John Carmack's QuakeCon 2011 Keynote 

  2. John Carmack's QuakeCon 2012 Keynote

  3. John Carmack's QuakeCon 2013 Keynote

    • functional programming
    • strong static type check
    • http://www.pcper.com/reviews/Editorial/John-Carmack-Keynote-Quakecon-2013
  4. GoingNative 2012

  5. GoingNative 2013

    1. Bjarne Stroustrup - The Essence of C++: With Examples in C++84, C++98, C++11, and C++14

    2. C++ Seasoning. (by Sean Parent)

      No Raw Loops
      • Difficult to reason about and difficult to prove post conditions
      • Error prone and likely to fail under non-obvious conditions
      • Introduce non-obvious performance problems
      • Complicates reasoning about the surrounding cod

      Alternatives to Raw Loops
      • Use an existing algorithm
      • Prefer standard algorithms if available
      No Raw Synchronization Primitives
      • You Will Likely Get It Wrong
      • They don't scale (Amdahl’s Law)
      No Raw Pointers
      • Prefer value semantic to reference semantic
    3. Writing Quick Code in C++, Quickly (by Andrei Alexandrescu)

      Intuition
      • Ignores aspects of a complex reality
      • Makes narrow/obsolete/wrong assumptions
      • “Fewer instructions = faster code”
      • “Data is faster than computation”
      • “Computation is faster than data”
      • The only good intuition: “I should time this.”

      Measuring gives you a leg up on experts who don’t need to measure

      Data Layout

      • Generally: small is fast
      • First cache line of an object is where it’s at
      • Sort member variables by hotness, descending
      Prefer zero to all other constants

      Returning containers by value worse than appending

    4. Don’t Help the Compiler (by Stephan T. Lavavej)

      Don't return by const value
      • Inhibits move semantics, doesn't achieve anything useful
      Don't move() when returning local X by value X

      • The NRVO and move semantics are designed to work together
      • NRVO applicable - direct construction is optimal
      • NRVO inapplicable - move semantics is efficient
      Don't return by rvalue reference
      • For experts only, extremely rare
      • Even the Standardization Committee got burned
      • Valid examples: forward, move, declval, get(tuple&&)
      Rely on template argument deduction
      • You control its inputs - the function arguments
      • Change their types/value categories to affect the output
      Avoid explicit template arguments, unless required
      • Required: forward<T>(t), make_shared<T>(a, b, c)
      • Wrong: make_shared<T, A, B, C>(a, b, c)
    5. Keynote: Herb Sutter - One C++
    6. An Effective C++11/14 Sampler (by Scott Meyers)

      Understand std::move and std::forward
      • std::move doesn't move
      • std::forward doesn't orward
      • neither generates code
      • they are simply casts
      • std::move unconditionally casts to rvalue (rvalue_cast)
      • std::forward conditionally casts to rvalue
      Declare functions noexcept whenever possible
      • fun() noexcept - more optimisation possibilities
      • fun() throw() - fewer optimisation possibilities
      • fun() - fewer optimisation possibilities
      • Some code may replace copying only with non-throwing moves
      • noexcept is part of function interface and client may depend on it. Don't use it only because current implementation allows it
      • noexcept is an operator, a bool value evaluated during compilation. Allows conditionally noexcept functions.
    7. The Care and Feeding of C++’s Dragons (by Chandler Carruth)

      Complexity
      • "You can solve every problem with another level of indirection, except for the problem of too many levels of indirection"
      • Complexity: the source and the solution to all programming problems
      • The cost of complexity is exponential.
      • Clever is not a Compliment!
      LLVM Sanitizers:
      • Compiler instrumentation dynamic analysis
      • Address Sanitizer, Thread Sanitizer, Memory Sanitizer, Undefined Behavior Sanitizer
      • Based on shadow memory, can’t be combined
      • Dynamic analysis onlyworks if you test your code!
    8. rand() Considered Harmful (by Stephan T. Lavavej)

      Uniform Random Number Generators
      • random_device
      • mt19937

      Distributions
      • uniform_int_distribution
    9. Inheritance Is The Base Class of Evil (by Sean Parent)

      Hide polymorphic inheritance from user of your API
      • There are no polymorphic types, only a polymorphic use of similar types
      • More flexible, Non-intrusive design doesn’t require class wrappers
      • More efficient,  Polymorphism is only paid for when needed
      • Less error prone,  Client doesn’t do any heap allocation, worry about object ownership or lifetimes
      • Exception and thread safe
  6. Exception-Safe Coding in C++ (Jon Kalb, Part 1, Part 2)

  7. The Problem with Time & Timezones - Computerphile

    • Leap second
    • Unix time
    • UTC
    • Astronomic time
  8. Linus Torvalds on git

  9. Unicode in C++ by James McNellis

    • UTF8, UTF-16, UTF-32
    • dynamic composition (Multiple representation)
      A(U+0041) + Umlaut(U+0308)=Ä
    • code unit vs. code point
    • What is length ? (Number of bytes, number of code units, number of code points)
    • Four normalisation forms
      NFC: Canonical Composed
      NFD: Canonical Decomposed
      NFKC: Compatibility Composed
      NFKD: Compatibility Decomposed
  10. Scott Meyers: Better Software — No Matter What

    1. 2\5
      • Inconsistency
    2. 3\5
      • Static analyse
      • Code review
      • Keyhole problem (on arbitrary restrictions - fixed size windows,fixed size hard coded in software)
    3. 4\5
    4. 5\5
      • Retrospectives !
  11. Plain threads are the 'GOTO' of today's computing (by  Hartmut Kaiser) Slides

    • Amdahl’s Law (Strong Scaling)
    • HPX - A General Purpose Runtime System for Applications of Any Scale
  12. CppCon 2014: The Philosophy of Google's C++ Code by Titus Winters

    • Optimize for reader not for the writer
    • Value the standard, but not idolize it
    • Be consistent
    • Avoid constructs that are dangerous or surprising
    • Avoid tricky and hard to maintain constructs
    • Don't use non-const references
    • Don't use exceptions
  13. Goals for Better Code - Implement Complete Types by Sean Parent

    • Regular type
    • Sometimes the most efficient basis operations are unsafe (violating class invariants)
  • The Silver Bullet Syndrome by Hadi Harir

    • There is no silver bullet (CORBA, COM, DCOM, WCF, node.js, J2EE, microservices, NoSQL)
    • Don't do "hype oriented programming)
    • Consider technology stability
    • Consider if it's proven technology
    • x86 mov is turing complete
    • MoVfuscator - compiler which compiles BrainFuck into mov only x86 assembly. Combined with compiler that compiles Basic into BF it gives Basic to movs compiler!
    • MoVfuscator2.0 - c compiler !!
    • x86 mov is turing complete
    • MoVfuscator - compiler which compiles BrainFuck into mov only x86 assembly. Combined with compiler that compiles Basic into BF it gives Basic to movs compiler!
    • MoVfuscator2.0 - c compiler !!

14. code::dive 2016 conference

15. cppCon 2016 conference

16. Rich Hickey


    • prefer simple over easy
    • data,values, functions are simple
    • declarative data manipulations
    • queues
    • transactions
    • avaoid incidental complexity (abything which is not required by the user0
    • Simplicity is the ultimate sophistication (Leonardo da Vinci)
  • Spec-ulatiion  by Rich Hickey
    • on how to manage software dependencies
    • SemVer 2 is broken - Minor and Patch components are irrelevant. Major component change is basically a library name change
    • Better would be to use time based versioning instead of SemVer2 

17 Pushing C# to the limit - Joe Albahari

  • very fast in-memory inter-process pipes
  • simple yet powerful remoting (10x faster that .net remoting)

18 7 Habits for Success (as explained by the ex-google tech lead)


  • Take Ownership - stop blaming other people, stop blaming you your boss, your teammates, your family or friends. If the project fails even if you did your part perfectly, it is also your failure. It is your responsibility, to make project to succeed. 
  • Accept Failure - do not pretend to be better than anyone else - you are not a superhuman - everyone make mistakes
  • What you do at 8pm matters - what do you do in your free time defines your future. If you watch TV you will be watching TV, if you learn new things you will likely use that knowledge.
  • Success is a lonely road, while failure is a crowded highway
  • The last 10% is the hardest. Finish it - when project is not finished it will not have any impact
  • Know why you want it - internal motivation is a key to be successful
  • Continuously learn 


Brak komentarzy:

Prześlij komentarz