dideler

<div id=":vz" class="ii gt m145ad5537035869c adP adO"><div id=":vy" class="a3s" style="overflow: hidden;"><div><div class="adM">
    </div><div bgcolor="#fafafa"><div class="adM">
      </div><table border="0" cellspacing="0" cellpadding="0" width="100%" bgcolor="#fafafa"><tbody><tr><td align="left" valign="middle" height="40" bgcolor="#e4eff7" style="color:#787878;font-family:Arial;padding:5px 30px 5px 30px">
            <div style="font-size:14px;letter-spacing:1px;font-weight:bold;color:#787878"><a href="https://eventing.coursera.org/redirect/K94Ky5AdlhxW-FQnYSZZtJPNSf_mKt0SlLY3BJoPtzGpi9uZUEt5y2t4OE_LPJ_BCElO-LwczCh98rRU3vjkFA.KYet1zUYKuWJE3yZ5nv7dQ.ew5zeZYivcmzO41tPxqLBchVIzZJsUl86CrpCEZL-BqfouGmyTiOsoHV6zgPWIft-5F1i2Ug42EeeOJS1yfZ-yZdoMF_Oc5dO2aP7vtdCqLHEQLkq4-vHwBL8nGe-T7Lypqw5CtuKyoVwWGNHb0s-n1mM3r5RfTIVyrGJYV4m8NKQI-m4K18qD0fszw5u0_OxR_24DUqzkXqfMfOD9_MwhEkfow89tPO2CYoYdWths3E9TQ3gK_KdRjJRm8AfgKVyacIGbanQ3tUENlDUy_E7E9YMuAmYCXUHe02U2p5FlEQW7LnDqTtG3MYC3uVCOW46Bs3_oIFzlryBTrariC7y1s3KXDtwE83vBW9t65D62

dideler

Lesson 1: Affordances and Signifiers

Don't solve the problem given (as it's stated), figure out what the real underlying problem is.

To understand design, you have to be a good observer and question things. Travel with a camera and take photos. Don't use flash, use natural lighting when possible.

Affordances are the relationships (read: possible actions) between an object and an entity (most often a person). For example, a chair affords sitting for a human. Affordances enable interactions between entities and objects (similarly, anti-affordances prevent or reduce interactions). The presence of an affordance is determined by the properties of the object and of the abilities of the entity who's interacting with the object.

Signifiers are signals, communication devices. These signs tell you about the possible actions; what to do, and where to do it. Signifiers are often visible, but invisible (secret) signifiers do exist, like clicking a YT video to play

dideler

Based on the article: Using checklists for code review

In general, people are pretty good at the code review process, but it's sometimes surprising what can slip through. A natural consequence of the way our brains look at the world is that it's easy to pay a lot of attention to small details and code style flubs, and completely miss the big picture.

Obviously, not everything is applicable for every change. If the review request isn't making any changes to UI, then skip the first two checklists entirely. If a change is a bug fix, typically don't review it for architecture and design principles.

Put the big stuff first (e.g. architecture). You don't want to work through a ton of small issues before realizing that everything has to be rewritten.

Do a pass through the code for each and every item in the checklist. By only looking for a very specific type of defect, each pass goes relatively quickly, even for large changes. Focu

dideler

The program below can take one or more plain text files as input. It works with python2 and python3.

Let's say we have two files that may contain email addresses:

1. file_a.txt

foo bar
ok ideler.dennis@gmail.com sup
 hey...user+123@example.com,wyd
hello world!

dideler

source 'http://rubygems.org'

gem 'plexus'
gem 'gratr' # dependency of plexus to visualize graphs

dideler

API Best Practices

Routes

Restricting routes

resources :zombies, only: [:index, :show]
resources :humans, except: [:destroy, :edit, :update] 

dideler

# Require this file in spec_helper.rb to show which cassettes are not being used
# after the test suite has run. Then you can decide if you want to delete them.

require 'vcr'
require 'set'
USED_CASSETTES = Set.new

module CassetteReporter
  def insert_cassette(name, options = {})
    USED_CASSETTES << VCR::Cassette.new(name, options).file

dideler

You can move quickly through various full-stack troubleshooting tasks in our mission-critical distributed system; You are highly motivated to create extremely reliable, secure and performant pieces of software and processes; You are constructive and you take feedback well, incorporating it in your day-to-day tasks; Your communication skills are stellar, even when operating under stress; You don’t just hack something together; You craft incredibly polished pieces of code; Test driven development comes naturally to you; Reducing your code coverage is not an option for you; You have astonishing tracking skills; Your bugs are always up-to-date and your projects are delivered on time.

From a RoR job posting by Apple Inc.

dideler

• First rule of functions is that they are small.
• They are smaller than that.
• Lots of little well-named functions because they will save you and everyone time.
• Most of us don’t have to worry about efficiency of function calls.
• Making functions small save time.
• Classes hide in long functions.
• Functions do One Thing.
• They do it well, and do it only.
• If you can extract one function from another, you should.

dideler

A formula that lays out, on a page-by-page basis, exactly what should happen when, in a screenplay.
Each page is roughly equivalent to a minute of screen time.
Page counts don’t need to be followed strictly, but it’s important to get the proportions fairly close.

Opening image (p. 1)

Sets the tone for the story and suggests the protagonist’s primary problem.

Theme is stated (p. 5)

A question or statement, usually made to the protagonist, indicating the story’s main thematic idea.