marco79cgn

let spotifyCredentials
let widget = await createWidget()
Script.setWidget(widget)
Script.complete()

async function createWidget() {

    let widget = new ListWidget()
    let spotifyIcon = await getImage("spotify-icon.png")
    widget.backgroundColor = new Color("1e2040")

oscarmorrison

##Date and Time

=TIMEVALUE(SUBSTITUTE("{{OccurredAt}}"," at ", " ")) + DATEVALUE(SUBSTITUTE("{{OccurredAt}}"," at ", " "))

##Date

=DATEVALUE(SUBSTITUTE("{{OccurredAt}}"," at ", " "))

##Time

jashkenas

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil

abo-abo

select repository_name, count(repository_name) as pushes, repository_description, repository_url
from [githubarchive:github.timeline]
where type="PushEvent"
  and repository_language="Emacs Lisp"
  and parse_utc_usec(created_at) >= parse_utc_usec('2014-01-01 00:00:00')
group by repository_name, repository_description, repository_url
order by pushes desc
limit 100

mankyKitty

(defmodule lfe_type_scan
  (export all))

(defun to-type-fun (t)
  "This function was taking the type atom 'atom and smooshing it into
\"atom()\" but this doesn't play well with how I've structured the fold
so I've left it for now whilst I tried other things."
  (list t)) ;; Until further notice

(defmacro with-spec args

emad-elsaid

require 'socket'
require 'base64'

Refresh = 1 # seconds to refresh image on server
screen_capture_command = 'screencapture -C -x tmp.png'
image = ''
latest = Time.now
server = TCPServer.new 3000

loop do

oubiwann

 $ cat ~/.lein/profiles.clj
 
{:user
  {:plugins
    [[org.clojure/clojure "1.5.1"]
     [lein-kibit "0.0.8"]
     [lein-exec "0.3.1"]
     [lein-cloverage "1.0.2"]
     [lein-midje "3.0.0"]
     [jonase/eastwood "0.0.2"]

plentz

# to generate your dhparam.pem file, run in the terminal
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

blowmage

Presenters in Rails

I have bemoaned the lack of a ViewModel in Rails many times, and I prefer using Presenters to simulate a ViewModel. But it turns out there is an object that does represent the state of the view in Rails apps. Its an instance of ActionView::Base that the controller calls view_context. We don't have much control of this object, but it seems like a logical place to put our view-specific behavior.

This code is an attempt at creating Presenters using modules. The module will be mixed into the view_context object. This is very similar to how a Decorator module will be mixed into a model object, only instead of being specific to the model is it specific to the view.

This means that testing your presenter is no different than testing any other module. So relying on dependencies such as other methods or instance variables can make testing difficult.

jschairb

#!/bin/sh
# Modified version of script found at
# http://devblog.springest.com/a-script-to-remove-old-git-branches

# This has to be run from master
git checkout master

# Update our list of remotes
git fetch origin
git remote prune origin