Copyright © 2016-2018 Fantasyland Institute of Learning. All rights reserved.
A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.
val square : Int => Int = x => x * x| ARDUINO_SKETCHBOOK = $(HOME)/Documents/Arduino/SKETCHBOOK | |
| ARDUINO_DIR = /Applications/Arduino.app/Contents/Resources/Java | |
| ARDMK_DIR = $(HOME)/Documents/Arduino/Arduino-Makefile | |
| BOARD_TAG = uno | |
| ARDUINO_PORT = /dev/cu.usb* | |
| ARDUINO_LIBS = Ethernet Ethernet/utility SPI WebServer | |
| include $(ARDMK_DIR)/arduino-mk/Arduino.mk |
| module ServiceFeed | |
| def self.included(base) | |
| base.send(:include, Mongoid::Document) | |
| base.send(:extend, ClassMethods) | |
| end | |
| module ClassMethods | |
| def acts_as_service_feed(opts={}) | |
| service_feed_id_name = "#{opts[:service_name]}_id" |
Dos aclaraciones:
Esto es muy abstracto.
La última vez que miré algo así fue con Sicard, en la universidad, hace muuuuchos años.
En un Interactive Proof System (IPS) tenés dos participantes, el que entrega los datos (demostrador) y el que los verifica (verificador). El demostrador alimenta al probador con información y el trabajo del verificador es, a partir de esa información, ver si lo que se dijo es cierto o no (buscando colisiones entre las respuestas/inconsistencias/contradicciones). Estas dos entidades son tan abstractas como cualquiera de las entidades que viste en Especiales 3 (autómatas, máquinas de Turing, etc).
Ahora, los demostrador son omniscientes pero no siempre "dicen la verdad". Es trabajo del probador (que es más bien limitado) encontrar las colisiones. Una forma muy eficiente de hacer esto es usar varios demostradores que no tengan comunicación entre sí (que no se puedan poner de acuerdo a la hora de alimentar al probador). Si los demostradores no se pueden poner de acuerdo entonc
Inheritance is a key concept in most object-oriented languages, but applying it skillfully can be challenging in practice. Back in 1989, M. Sakkinen wrote a paper called Disciplined inheritance that addresses these problems and offers some useful criteria for working around them. Despite being more than two decades old, this paper is extremely relevant to the modern Ruby programmer.
Sakkinen's central point seems to be that most traditional uses of inheritance lead to poor encapsulation, bloated object contracts, and accidental namespace collisions. He provides two patterns for disciplined inheritance and suggests that by normalizing the way that we model things, we can apply these two patterns to a very wide range of scenarios. He goes on to show that code that conforms to these design rules can easily be modeled as ordinary object composition, exposing a solid alternative to tradi
| #!/usr/bin/env sh | |
| ## | |
| # This is script with usefull tips taken from: | |
| # https://github.com/mathiasbynens/dotfiles/blob/master/.osx | |
| # | |
| # install it: | |
| # curl -sL https://raw.github.com/gist/2108403/hack.sh | sh | |
| # |
| class OauthController < ApplicationController | |
| class ApiOAuthError < StandardError | |
| attr_accessor :code, :description, :uri, :state | |
| def initialize(code, description, uri = nil, state = nil) | |
| @code = code | |
| @description = description | |
| @uri = uri |
| For each Ruby module/class, we have Ruby methods on the left and the equivalent | |
| Clojure functions and/or relevant notes are on the right. | |
| For clojure functions, symbols indicate existing method definitions, in the | |
| clojure namespace if none is explicitly given. clojure.contrib.*/* functions can | |
| be obtained from http://github.com/kevinoneill/clojure-contrib/tree/master, | |
| ruby-to-clojure.*/* functions can be obtained from the source files in this | |
| gist. | |
| If no method symbol is given, we use the following notation: |
