Google App Engine Recipe
Google App Engine (GAE) provides a range of hosting options from pure PaaS (App Engine Classic) through Managed VMs to fully self-managed or container-driven Compute Engine instances. Vodka works great with all of these but requires a few changes to the usual examples to run on the AppEngine Classic and Managed VM options. With a small amount of effort though it’s possible to produce a codebase that will run on these and also non-managed platforms automatically.
We’ll walk through the changes needed to support each option.
Standalone
Wait? What? I thought this was about AppEngine! Bear with me - the easiest way to show the changes required is to start with a setup for standalone and work from there plus there’s no reason we wouldn’t want to retain the ability to run our app anywhere, right?
We take advantage of the go build constraints or tags to change how we create and run the Vodka server for each platform while keeping the rest of the application (e.g. handler wireup) the same across all of them.
First, we have the normal setup based on the examples but we split it into two files - app.go
will
be common to all variations and holds the Vodka instance variable. We initialise it from a function
and because it is a var
this will happen before any init()
functions run - a feature that we’ll
use to connect our handlers later.
app.go
package main
// reference our vodka instance and create it early
var e = createMux()
A separate source file contains the function to create the Vodka instance and add the static
file handlers and middleware. Note the build tag on the first line which says to use this when not
bulding with appengine or appenginevm tags (which thoese platforms automatically add for us). We also
have the main()
function to start serving our app as normal. This should all be very familiar.
app-standalone.go
// +build !appengine,!appenginevm
package main
import (
"github.com/insionng/vodka"
"github.com/insionng/vodka/engine/standard"
"github.com/insionng/vodka/middleware"
)
func createMux() *vodka.Vodka {
e := vodka.New()
e.Use(middleware.Recover())
e.Use(middleware.Logger())
e.Use(middleware.Gzip())
e.Use(middleware.Static("public"))
return e
}
func main() {
e.Run(standard.New(":8080"))
}
The handler-wireup that would normally also be a part of this Vodka setup moves to separate files which
take advantage of the ability to have multiple init()
functions which run after the e
Vodka var is
initialised but before the main()
function is executed. These allow additional handlers to attach
themselves to the instance - I’ve found the Group
feature naturally fits into this pattern with a file
per REST endpoint, often with a higher-level api
group created that they attach to instead of the root
Vodka instance directly (so things like CORS middleware can be added at this higher common-level).
users.go
package main
import (
"net/http"
"github.com/insionng/vodka"
"github.com/insionng/vodka/middleware"
)
type (
user struct {
ID string `json:"id"`
Name string `json:"name"`
}
)
var (
users map[string]user
)
func init() {
users = map[string]user{
"1": user{
ID: "1",
Name: "Wreck-It Ralph",
},
}
// hook into the vodka instance to create an endpoint group
// and add specific middleware to it plus handlers
g := e.Group("/users")
g.Use(middleware.CORS())
g.POST("", createUser)
g.GET("", getUsers)
g.GET("/:id", getUser)
}
func createUser(c vodka.Context) error {
u := new(user)
if err := c.Bind(u); err != nil {
return err
}
users[u.ID] = *u
return c.JSON(http.StatusCreated, u)
}
func getUsers(c vodka.Context) error {
return c.JSON(http.StatusOK, users)
}
func getUser(c vodka.Context) error {
return c.JSON(http.StatusOK, users[c.P(0)])
}
If we run our app it should execute as it did before when everything was in one file although we have at least gained the ability to organize our handlers a little more cleanly.
AppEngine Classic and Managed VMs
So far we’ve seen how to split apart the Vodka creation and setup but still have the same app that still only runs standalone. Now we’ll see hwo those changes allow us to add support for AppEngine hosting.
Refer to the AppEngine site for full configuration and deployment information.
app.yaml configuration file
Both of these are Platform as as Service options running on either sandboxed micro-containers
or managed Compute Engine instances. Both require an app.yaml
file to describe the app to
the service. While the app could still serve all it’s static files itself, one of the benefits
of the platform is having Google’s infrastructure handle that for us so it can be offloaded and
the app only has to deal with dynamic requests. The platform also handles logging and http gzip
compression so these can be removed from the codebase as well.
The yaml file also contains other options to control instance size and auto-scaling so for true
deployment freedom you would likely have separate app-classic.yaml
and app-vm.yaml
files and
this can help when making the transition from AppEngine Classic to Managed VMs.
app-engine.yaml
application: my-application-id # defined when you create your app using google dev console
module: default # see https://cloud.google.com/appengine/docs/go/
version: alpha # you can run multiple versions of an app and A/B test
runtime: go # see https://cloud.google.com/appengine/docs/go/
api_version: go1 # used when appengine supports different go versions
default_expiration: "1d" # for CDN serving of static files (use url versioning if long!)
handlers:
# all the static files that we normally serve ourselves are defined here and Google will handle
# serving them for us from it's own CDN / edge locations. For all the configuration options see:
# https://cloud.google.com/appengine/docs/go/config/appconfig#Go_app_yaml_Static_file_handlers
- url: /
mime_type: text/html
static_files: public/index.html
upload: public/index.html
- url: /favicon.ico
mime_type: image/x-icon
static_files: public/favicon.ico
upload: public/favicon.ico
- url: /scripts
mime_type: text/javascript
static_dir: public/scripts
# static files normally don't touch the server that the app runs on but server-side template files
# needs to be readable by the app. The application_readable option makes sure they are available as
# part of the app deployment onto the instance.
- url: /templates
static_dir: /templates
application_readable: true
# finally, we route all other requests to our application. The script name just means "the go app"
- url: /.*
script: _go_app
Router configuration
We’ll now use the build constraints again like we did when creating
our app-standalone.go
instance but this time with the opposite tags to use this file if the build has
the appengine or appenginevm tags (added automatically when deploying to these platforms).
This allows us to replace the createMux()
function to create our Vodka server without any of the
static file handling and logging + gzip middleware which is no longer required. Also worth nothing is
that GAE classic provides a wrapper to handle serving the app so instead of a main()
function where
we run the server, we instead wire up the router to the default http.Handler
instead.
app-engine.go
// +build appengine
package main
import (
"github.com/insionng/vodka"
"github.com/insionng/vodka/engine/standard"
"net/http"
)
func createMux() *vodka.Vodka {
e := vodka.New()
// note: we don't need to provide the middleware or static handlers, that's taken care of by the platform
// app engine has it's own "main" wrapper - we just need to hook vodka into the default handler
s := standard.New("")
s.SetHandler(e)
http.Handle("/", s)
return e
}
Managed VMs are slightly different. They are expected to respond to requests on port 8080 as well
as special health-check requests used by the service to detect if an instance is still running in
order to provide automated failover and instance replacement. The google.golang.org/appengine
package provides this for us so we have a slightly different version for Managed VMs:
app-managed.go
// +build appenginevm
package main
import (
"github.com/insionng/vodka"
"github.com/insionng/vodka/engine/standard"
"google.golang.org/appengine"
"net/http"
"runtime"
)
func createMux() *vodka.Vodka {
e := vodka.New()
// note: we don't need to provide the middleware or static handlers
// for the appengine vm version - that's taken care of by the platform
return e
}
func main() {
// the appengine package provides a convenient method to handle the health-check requests
// and also run the app on the correct port. We just need to add Vodka to the default handler
s := standard.New(":8080")
s.SetHandler(e)
http.Handle("/", s)
appengine.Main()
}
So now we have three different configurations. We can build and run our app as normal so it can
be executed locally, on a full Compute Engine instance or any other traditional hosting provider
(including EC2, Docker etc…). This build will ignore the code in appengine and appenginevm tagged
files and the app.yaml
file is meaningless to anything other than the AppEngine platform.
We can also run locally using the Google AppEngine SDK for Go either emulating AppEngine Classic:
goapp serve
Or Managed VMs:
gcloud config set project [your project id]
gcloud preview app run .
And of course we can deploy our app to both of these platforms for easy and inexpensive auto-scaling joy.
Depending on what your app actually does it’s possible you may need to make other changes to allow switching between AppEngine provided service such as Datastore and alternative storage implementations such as MongoDB. A combination of go interfaces and build constraints can make this fairly straightforward but is outside the scope of this recipe.


G261.9+5.5
- Right Ascension: 09 04 20
- Declination: −38 42
- Size (/arcmin): 40×30
- Type: S
- Flux density at 1 GHz (/Jy): 10?
- Spectral Index: 0.4?
- Radio: Faint shell with little limb brightening.
References:
- Hill 1967, AuJPh, 20, 297. Parkes 64-m at 2650 MHz (7.'5: S=7 Jy) also S1410 MHz=8 Jy, S81.5 MHz=25 Jy.
ADS
- Colomb & Dubner 1980, A&A, 82, 244. Argentine 30-m dish at 1.4 GHz, for HI possibly associated with remnant.
ADS
- Kesteven & Caswell 1987, A&A, 183, 118. MOST at 843 MHz (44''×71'').
ADS
- Green et al. 1997, AJ, 114, 2058. Parkes 64-m OH observations.
ADS
Last updated: 13 Aug 1998
home |
documentation |
detailed listings |
summary listings
Dave Green/Cambridge, UK/


|
| Local Methods | ||
| Managed Object Types | Data Object Types | All Properties | All Methods |
Properties
| Name | Type | Description |
|---|---|---|
| None | ||
| Properties inherited from Profile | ||
| complianceStatus, config, createdTime, description, entity, modifiedTime, name |
Methods
| Methods defined in this Managed Object |
|---|
| UpdateClusterProfile |
| Methods inherited from Profile |
| AssociateProfile, CheckProfileCompliance_Task, DestroyProfile, DissociateProfile, ExportProfile, RetrieveDescription |
Parameters
| Name | Type | Description |
|---|---|---|
| _this | ManagedObjectReference | A reference to the ClusterProfile used to make the method call. |
| config | ClusterProfileConfigSpec |
Specification which describes the changes.
|
Return Value
| Type | Description |
|---|---|
| None |
Faults
| Type | Description |
|---|---|
| DuplicateName | Thrown if the profile with the new name already exists. |
| RuntimeFault | Thrown if any type of runtime fault is thrown that is not covered by the other faults; for example, a communication error. |
Events
| Type | |
|---|---|
| None |
| Top of page | Local Methods | ||
| Managed Object Types | Data Object Types | All Properties | All Methods |


Practices and Actions - Wittgensteinian Critique of Bourdieu and Giddens
289 - Critique of Bourdieu "...it is not with practices but with the objective conditions established by them that dispositions are homologously structured." For Bourdieu, these objective conditions have two dimensions: * statistical regularities - such as price curves, chances of access to education, frequency of holidays * networks of groups are defined by * possession of certain cultural, symbolic, and material capitals * pursuit of certain actions and lifestyles * Economic class is especially important
290 * "It is logically wiser to postulate that habitus is srtuctured homologously with the action manifolds it produces."
290 - Giddens
"A practice is a nexus of actions...The renewal of structure whereby practices perpetuate themselves must come about through the actions that compose them" * Actors in a field of practices, thought their participation in practicesm reinforce and reproduce the structures that hence organize practices.
As Schatzki writes:
"...actors draw on structures, thereby participating in practices and reinterating their own organizing structures. Hence, the structures of practices also govern practices' constituent actions."
291 * Giddens understanding of structure: 1. Rules 2. Resources - the medium through which social power is enacted. Giddens notes that social power is understood here as the capacity to bring about change in a situation where doing so is subject to the actions of others. This seems (to me at least) to be Giddens account of agency. In this way, we can say more directly that use of a resource is the act of securing the actions of other required to bring about an outcome.
- So structure both organizes and governs actions (that make up practices) is itself made up of sets of rules.
- rules are codes and norms, which are "methodologically applied" and "generalizable procedures of action" that arise from the practical activities of daily life (we could paraphrase to say that rules are norms that arise from "going about" one's daily activities). It is through repeated observance of these rules (largely determined by dispositions inculcated by cultural upbringing, societal/cultural pressure or judgment, and the act(s) repeated observance themselves) that these rules are codified, so to speak, although it seems neither Giddens nor Wittgenstein construe the process by which rules are developed and perpetuated that concretely. As Schatzki notes, Giddens was careful to observe that rules are always only "interpreted." "Rules themselves are procedures of action, ways of going on" (Schatzki 1997, p. 291). We see here the similarities in the phrase "ways of going on" and W's understanding of practices and rules as "what it makes sense to do".
- Resources
- "Through the use of or reliance on resources, actors bring others to perform actions through which specific outcomes are secured."
292 - Bourdieu v. Giddens For Bourdieu, habitus alone is what determines action. Giddens maintains that actions can also be determined by reasons (the unspoken grounds for actions) and desires (deep, perhaps subconscous motivations).
292-93 Summary of Bourdieu's system of oppostions: 1. organize practices by structuring arrays of actions - what is done, when, and where. 2. determine actions by structuring the selection of (sensible) actions For Bourdieu, the identity of an action stems from oppositions that organize practices. Summary of Giddens: * Rules and resources: 1. govern practices by defining fields of possible actions. 2. determine what actions are possible via a practical consciousness that situates/orients activity For Giddens, an actions receive at least part of its identity from the organization of the practice of which it is a part.
For both, practices are ontologically prior to actions and the existence of individual actions are bound up with manifolds of activity.
What the eff are manifolds?
294
"Giddens and Bourdieu contest the adequacy of representationism as a complete or even partial account of human activity and seek to do justice to the practice nature of action by rooting human activity in a norepresentational stratum, which also undergirds the resultingly limited role that representations play in determining action."
- representational approaches are being replaced with conceptions that acknowledge "creative action." So non-rep accounts believe that representations play at most a limited role in determining actions.
295
"Powerful considerations against the possibility of representing the content of practical understanding, the ability to go on intelligibly to others, are found in the works of Wittgenstein. Most discussions of the bearing of his texts on practical understanding fcus on his remarks about rule following, where a rule is an explicit formulation. * The considerations that argue against representability of practical understandings, on the other hand, are found in his disucssion of games and family resemblances * (e.g., Wittgenstein 1958, sec 65-79)."
Collapsing, or even just decentering, the determination of action in practical understanding represents a great advance over representational models of activity. Representationism is burdened by lingering, if not overtly, Neo-Cartesian conceptions of representation; by the baneful assumption that mental conditions are discrete states in any sense stronger than being described in specific words; and/or by indadequately explicated notion of causal relations between representations and actions. (Schatzki, 1997)
PI Sec. 49
"Name is not yet a move in a language game...with the mere naming of a thing, nothing has yet been done. Nor has it a name except in a game. This is what Frege meant too when he said that a word has a meaning only in the context of a sentence." {Emphasis in original}


No results found
Back
Admin Settings
Add
Today
Games
Online
Upcoming
Finished
Nationality:
*
Choose
Division:
*
Choose
Season:
*
Choose
Rounds:
*
Choose
Status:
*
Choose
Shirt
No games found
Latest Games
Details
Edit
Delete
Are you sure?
×


A paragraph (from the Greek paragraphos, "to write beside" or "written beside") is a self-contained unit of a discourse in writing dealing with a particular point or idea. A paragraph consists of one or more sentences.
Though not required by the syntax of any language, paragraphs are usually an expected part of formal writing, used to organize longer prose.
Blockquotes
A block quotation (also known as a long quotation or extract) is a quotation in a written document, that is set off from the main text as a paragraph, or block of text, and typically distinguished visually using indentation and a different typeface or smaller size quotation.
The
b element is stylistically different text from normal text, without any special importance
The i element is text that is set off from the normal text
The
u element is text with an unarticulated, though explicitly rendered, non-textual annotation
This text is deleted
and
This text is inserted
This text has a strikethrough
Superscript®
Subscript for things like H2O
This small text is small for for fine print, etc.
Abbreviation: HTML
Keybord input: Cmd
This text is a short inline quotation
This is a citation
The dfn element indicates a definition.
The
mark element
indicates a highlight
This is what inline code looks like.
This is sample output from a computer program
The variarble element, such as x = y
Preformatted Text
P R E F O R M A T T E D T E X T
! " # $ % & ' ( ) * + , - . /
0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O
P Q R S T U V W X Y Z [ \ ] ^ _
` a b c d e f g h i j k l m n o
p q r s t u v w x y z { | } ~
HR
Unordered List
This is a list item in an unordered list
An unordered list is a list in which the sequence of items is not important. Sometimes, an unordered list is a bulleted list. And this is a long list item in an unordered list that can wrap onto a new line.
Lists can be nested inside of each other
This is a nested list item
This is another nested list item in an unordered list
This is the last list item
Ordered List
This is a list item in an ordered list
An ordered list is a list in which the sequence of items is important. An ordered list does not necessarily contain sequence characters.
Lists can be nested inside of each other
This is a nested list item
This is another nested list item in an ordered list
This is the last list item
Definition List
Definition List
A number of connected items or names written or printed consecutively, typically one below the other.
This is a term.
This is the definition of that term, which both live in a dl.
Here is another term.
And it gets a definition too, which is this line.
Here is term that shares a definition with the term below.


val fitnessFunction: FitnessFunction<T>
A function that can measure the fitness of a program.
This property should be provided at construction time.


Hi! I'm Jeremy. I'm from Cupertino, CA. I'm in the class of 2020 at Duke, studying Computer Science.
I started using a computer around when I was 4 or 5 years old. It was one of those ancient ThinkPads my parents used for work. I've used many types of computers, on most major operating systems. (Pocket PCs, phones, laptops, custom desktops, Raspberry Pi's, etc.)I use computers for productivity, gaming, messaging, and pretty much everything else on a daily basis. I think a computer scientist designs and builds features for software on a daily basis.
My introductory programming course I took in high school had a game design project using Java Swing/Applets, and I think the experience of building that terrible game was something that led me to study computer science. I'm taking this course because my friend told me to register 15 minutes before class started and because I thought web development might be a useful skill.
For front-end, some experience with UI/UX design and knowledge of HTML/CSS would be helpful in building attractive and user-friendly interfaces. For back-end, knowing a language like JS or Python and an understanding of how databases work would be useful. Since I'm planning on being a software engineer after graduating, I see myself using computers a lot more for coding and other work-related tasks in the future.
floot.io: This is a good website because of its simplicity and the somewhat haphazard typeface, which is cohesive with its simple and humorous purpose. It's very simple to navigate the website, and it is very clear what the user can do on the site.
getpostman.com: This is a good website because it has a wonderful color scheme and a very clear and easily navigatable layout. It manages to look great while still providing a lot of utility and information.
theroommovie.com: This is a bad website because it has no real logic to its layout and is difficult to navigate. It also has a fairly ugly color scheme and small text. Also the map on the website is not interactive, and is simply a screenshot from Google Maps with Wiseau's face pasted all over it. (There are also numerous typos and strange graphics/images scattered throughout)
arngren.net: This is a bad website because its layout is ugly and crowded. It's styled like the classified section of a newspaper, and doesn't scale to the size of your browser window, such that you have to scroll right and down to see more listings. There is also little to no logical sorting of the listings.


Caritas engaged to be married... !
February 18 2007, 9:29 PM
This Saturday I was invited to a traditional ceremony which officializes the engagement between the fiancés, called "la dote".
The family of the man have to pay money to the family of the jill to get their "cow" (that's really how they call it!).
It was very nice to participate to such a traditional party. I have recorded many videos. I will share them once I'll be back in Europe (remember that the Internet connection is very bad here).
The fiancée, Caritas, is just in the middle. The picture on the right shows the part for the family of the girl.
To show the unity of both families, they drink the local beer (made of Solgo) in a same bucket


You recently requested to reset your password for your mussen.tk account with this email. Click the button bellow to reset it.
If you did not request a password reset please ignore this email or reply to let us know
If you have any questions about your account or any other matter, please feel free to contact us at:
<EMAIL_ADDRESS>or by phone at (+49) 176 713 117 46
Thanks,
mussen Team
If you're having trouble clicking the password reset button, copy and paste the URL below into your web browser.
-forgotPasswordURL-