TL;DR
Install Postgres 9.6, and then:
sudo pg_dropcluster 9.6 main --stop
sudo pg_upgradecluster 9.5 main
sudo pg_dropcluster 9.5 mainTL;DR
Install Postgres 9.6, and then:
sudo pg_dropcluster 9.6 main --stop
sudo pg_upgradecluster 9.5 main
sudo pg_dropcluster 9.5 main| // | |
| // SimpleMediaSaver.swift | |
| // | |
| // Created by Dennis Lysenko on 27-09-16. | |
| // Copyright © 2016 Dennis Lysenko. All rights reserved. | |
| // https://gist.github.com/dennislysenko/5388cacb83b754e8983e99bff7fef2d2 | |
| // | |
| // This gist is licensed under the terms of the MIT license. | |
| // |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
| package main | |
| import ( | |
| "fmt" | |
| "reflect" | |
| ) | |
| type Aaa struct { | |
| a string | |
| } |
| package main | |
| import ( | |
| "fmt" | |
| "log" | |
| "net/http" | |
| ) | |
| func main() { | |
| // We need to cast handleRoot to a http.HandlerFunc since wrapHandlerWithLogging |
| The MIT License (MIT) | |
| Copyright (c) 2016 Zev Eisenberg | |
| Permission is hereby granted, free of charge, to any person obtaining a copy of | |
| this software and associated documentation files (the "Software"), to deal in | |
| the Software without restriction, including without limitation the rights to | |
| use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of | |
| the Software, and to permit persons to whom the Software is furnished to do so, | |
| subject to the following conditions: |
| #!/usr/bin/env swift | |
| // | |
| // PrintBootCampESDInfo.swift | |
| // | |
| // Created by nuomi1 on 8/5/18. | |
| // Copyright © 2018年 nuomi1. All rights reserved. | |
| // | |
| import Foundation |
TL;DR
Install Postgres 9.5, and then:
sudo pg_dropcluster 9.5 main --stop
sudo pg_upgradecluster 9.3 main
sudo pg_dropcluster 9.3 main04/26/2103. From a lecture by Professor John Ousterhout at Stanford, class CS142.
This is my most touchy-feely thought for the weekend. Here’s the basic idea: It’s really hard to build relationships that last for a long time. If you haven’t discovered this, you will discover this sooner or later. And it's hard both for personal relationships and for business relationships. And to me, it's pretty amazing that two people can stay married for 25 years without killing each other.
[Laughter]
> But honestly, most professional relationships don't last anywhere near that long. The best bands always seem to break up after 2 or 3 years. And business partnerships fall apart, and there's all these problems in these relationships that just don't last. So, why is that? Well, in my view, it’s relationships don't fail because there some single catastrophic event to destroy them, although often there is a single catastrophic event around the the end of the relation