This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| // lifecycle.js | |
| // | |
| // This example demonstrates how to start, use and eventually shut down a node.js server. Many | |
| // node tutorials will tell you to completely restart a node process when changing a http | |
| // server's behavior. This is good advice, since it can limit the effect of memory leaks and | |
| // you don't have to worry about cross-version side effects on your business logic. But | |
| // every now and again you'll run across a situation where it's impractical to restart a | |
| // node process to upgrade server behaviour. For instance, we once made an "intelligent" | |
| // proxy that would change it's logging and routing behaviour based on whether it (or we) | |
| // thought an attack was happening. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| { | |
| "production": { | |
| "port": 80, | |
| "httpsify": true | |
| }, | |
| "staging": { | |
| "port": 8080, | |
| "default": "http://127.0.0.1:19000", | |
| "hosts": [ | |
| { "host": "#lo", "target": "http://127.0.0.1:19002" }, |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| // HashRouter.js - an object that routes through a table to an object + method | |
| // based on a the "hash" portion of a http(s) URL. Designed to be much, much | |
| // simpler than the Backbone router. | |
| // Copyright (c) 2015 Meadhbh S. Hamrick | |
| // | |
| // 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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| var states = [ | |
| { name: "Alabama" }, | |
| { name: "Alaska" }, | |
| { name: "Arizona" }, | |
| { name: "Arkansas" }, | |
| { name: "California" }, | |
| { name: "Colorado" }, | |
| { name: "Connecticut" }, | |
| { name: "Delaware" }, | |
| { name: "Florida" }, |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # example.dsd | |
| # | |
| # This file contains a "DSD Message." DSD stands for "Dynamic Structured Data." | |
| # It is a specification for messages that look a little like JSON, but have | |
| # comments and a few features that makes it slightly easier to parse on small | |
| # (8-bit) CPUs. But don't worry about that right now. This document is meant | |
| # to give you the "flavour" of DSD without weighing you down with specifics. | |
| # The first thing you'll notice about DSD is that (like JSON) virtually every | |
| # DSD message you'll likely see is a dictionary (pretty much the same thing |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| // dsdm.dsdm | |
| // | |
| // DSD/Message : Like Partial Regexes, but for Message Flows | |
| // | |
| // This file introduces some of the concepts of DSD/Message, a language for describing the content and intent of message flows | |
| // between cooperating distributed systems. DSD/Message (aka DSD/M) is used by protocol designers to succinctly define the content | |
| // of protocol messages in loosely coupled systems. It defines two messaging patterns: EVENT and REQUEST / RESPONSE which behave | |
| // like you might imagine. DSD/M also includes a macro capability to allow developers to easily reuse message constructions. The | |
| // VARIANT construction allows developers to unambiguously denote changes in message structure based on specific values of specific | |
| // message omponents. (Don't worry, this is a simple concept, it just sounds complicated when described formally.) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Read this file first. | |
| Then read the comments at the top of parity_test.c | |
| Then read the comments above each algorithm implementation in parity.c | |
| So there I was talking about efficient implemetation of fundamental functions | |
| with Palmer over at SiFive. Back in the day, I used to participate in informal | |
| contests on rec.games.programmer to see who could craft the most efficient | |
| implementations for population count or bit reversal or bit-blitting. For | |
| programmer types, it's great fun. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| XML, JSON or Binary : Does It Matter? | |
| Of course it matters. But with a tiny amount of effort, it doesn't have to matter much. | |
| This document describes a way of thinking about structured data and it's use in distributed applications. When implementing web-based APIs, developers traditionally use a well-supported message format such as JSON or XML. In applications where there is a perceived need for processing speed, custom binary formats are sometimes utilized. Each format has it's own benefits and drawbacks and this document will not argue their relative merits. It will, however, recommend an approach which abstracts away details of the specific message format (XML, JSON, binary) and focuses the application developer on more important aspects of application design. | |
| We start by examining the benefits and limitations of each message format, then describe an XML DTD and sample tagged binary format which can be mechanically converted into other described formats. We then describe how these formats can be used w |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| This text is taken from LinkedIn, where it was a response to this article by Bret Reckard at | |
| Sequoia. Bret's article is reasonably well written and contains decent advice if you're a software | |
| engineer looking to jump into a startup and become a VP of Engineering. Go check this one out, | |
| it's short and worth a read: | |
| https://www.linkedin.com/pulse/accelerate-your-path-vpe-join-series-startup-bret-reckard/ | |
| And now this is my response, which was originally a LinkedIn post plus a number of comments. I'm | |
| reconstructing it here 'cause it's a lot easier to read without trying to guess which order I | |
| originally posted things in. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| In Defense of Two Spaces After a Period | |
| I spend more time than is healthy worrying about software documentation. Don't get me wrong, I enjoy coding. I enjoy the process of investigating problems, possibly breaking them down into sub-problems and then searching my toolbox of conceptual solutions to find the one that's *just right*. But communicating a developer's intent clearly is an important part of constructing a solution. If you work in a team with other software developers, communicating intent is of vital importance. Even if you work in isolation, documenting your intent is important so that when you eventually come back to your code several years later, you have a chance of understanding what you were trying to do. | |
| And it was while I was in deep thought about documenting software that I thought that maybe, just maybe, there's justification for two spaces after a period in the modern world. | |
| I frequently use EMACS to edit files; sometimes I use VI, I'm not a zealot. So I like to see text files as |