ahmedahamid

// 
// (1) C++: - Defining a dictionary [key type=string, value type=int]
//          - No easy way to initialize.
// 
map<string, int> dict;
//
// (1`) C++11: Defining and initializing a dictionary [key type=string, value type=int]
//
map<string, int> dict
{

ahmedahamid

// 
// (1) C#: Defining an initializing a dictionary [key type=string, value type=int]
//
Dictionary<string, int> dict = new Dictionary<string, int>()
{
    {"Eve",    101},
    {"George", 150},
    {"Emma",   200}
};
// 

swlaschin

(*
enterprise-tic-tac-toe-2.fsx

Follow up to the example of implementing "enterprise" tic-tac-toe in a functional way.
* Added true capability based security.

Related blog post: http://fsharpforfunandprofit.com/posts/enterprise-tic-tac-toe-2/

*)

ctran

import Graphics.Element (Element, flow, down)
import List (map)
import Text (asText)

main : Element
main = 
  let fizzBuzz n = case (n % 3, n % 5) of
    (0, 0) -> "FizzBuzz"
    (0, _) -> "Fizz"
    (_, 0) -> "Buzz"

JulienPalard

#!/usr/bin/env python


def curry(func):
    """
    Decorator to curry a function, typical usage:

    >>> @curry
    ... def foo(a, b, c):
    ...    return a + b + c

rohit-jamuar

#!/usr/bin/python

def balanced_delimiters(s):
    '''
    This function determines if the input string ('s') has balanced number of braces. 
    All the opening braces are appended to 'data'. As soon as a closing brace is
    encountered, the last entry in 'data' is matched with it. If the closing brace is
    the opposite of the last element in 'data' - opening braces and their corresponding
    closing braces are stored in 'braces', we have a match and the the last element
    is popped-off 'data'. This process is continued till either all the elements of 's'

MSK61

#include <iostream>
#include <map>
#include <stack>

bool IsBalanced(const char delimStr[]) {
    using std::make_pair;
    std::map< char, char > delims;
    const char* curChar = delimStr;
    std::stack< char > store;

renatoathaydes

#!/usr/bin/env groovy

import org.eclipse.jetty.server.Server
import org.eclipse.jetty.servlet.*
import groovy.servlet.*

@Grab(group='org.eclipse.jetty.aggregate', module='jetty-all', version='7.6.15.v20140411')
def startJetty() {
    def server = new Server(8080)

dhh

# Original Rails controller and action
class EmployeesController < ApplicationController
  def create
    @employee = Employee.new(employee_params)
    
    if @employee.save
      redirect_to @employee, notice: "Employee #{@employee.name} created"
    else
      render :new
    end

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.