| This note explains how to build Postgres from source and setup to debug it using LLDB on a Mac. I used this technique to research this article: | |
| http://patshaughnessy.net/2014/10/13/following-a-select-statement-through-postgres-internals | |
| 1. Shut down existing postgres if necessary - you don’t want to mess up your existing DB or work :) | |
| $ ps aux | grep postgres | |
| pat 456 0.0 0.0 2503812 828 ?? Ss Sun10AM 0:11.59 postgres: stats collector process | |
| pat 455 0.0 0.0 2649692 2536 ?? Ss Sun10AM 0:05.00 postgres: autovacuum launcher process | |
| pat 454 0.0 0.0 2640476 304 ?? Ss Sun10AM 0:00.74 postgres: wal writer process | |
| pat 453 0.0 0.0 2640476 336 ?? Ss Sun10AM 0:00.76 postgres: writer process |
Availability and quality of developer tools are an important factor in the success of a programming language. C/C++ has remained dominant in the systems space in part because of the huge number of tools tailored to these lanaguages. Succesful modern languages have had excellent tool support (Java in particular, Scala, Javascript, etc.). Finally, LLVM has been successful in part because it is much easier to extend than GCC. So far, Rust has done pretty well with developer tools, we have a compiler which produces good quality code in reasonable time, good support for debug symbols which lets us leverage C++/lanaguge agnostic tools such as debuggers, profilers, etc., there are also syntax highlighting, cross-reference, code completion, and documentation tools.
In this document I want to layout what Rust tools exist and where to find them, highlight opportunities for tool developement in the short and long term, and start a discussion about where to focus our time an
A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."
- Does the design expect failures to happen regularly and handle them gracefully?
- Have we kept things as simple as possible?
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
#Indico client-side MVC It's time to go full MVC in Indico!
We all want our architecture to be simple, yet beautiful.
When developing applications using just jQuery, the piece missing is a way to structure and organize your code. It’s very easy to create a JavaScript app that ends up a tangled mess of jQuery selectors and callbacks, all desperately trying to keep data in sync between the HTML for your UI, the logic in your JavaScript, and calls to your API for data.
A number of modern JavaScript frameworks provide developers an easy path to organizing their code using variations of a pattern known as MVC (Model-View-Controller). MVC separates the concerns in an application into three parts:
| from indico.util.fossilize import IFossil | |
| from MaKaC.common.Announcement import getAnnoucementMgrInstance | |
| @HTTPAPIHook.register | |
| class RangeHook(HTTPAPIHook): | |
| TYPES = ('num', 'char') | |
| RE = r'(?P<start>[0-9]+|[a-z])-(?P<end>[0-9]+|[a-z])' | |
| DEFAULT_DETAIL = 'simple' | |
| MAX_RECORDS = { |
The following document is a written account of the Code School screencasting framework. It should be used as a reference of the accompanying screencast on the topic.
You're probably aren't going to take the time to read this document if you're not interested, but there are a lot of nice side effects caused by learning how to create quality screencasts.
- Communicating more effectively - At Envy Labs we produce screencasts for our clients all the time. Whether it's demoing a new feature or for a presentation for an invester, they're often much more effective and pleasent than a phone call or screen sharing.