Code maintainability encapsulates the idea of how easy it is to alter existing features or add new features. Changes to software originate in various places: User requirements tend to change with time, new features are requested and existing features may be need to be modified. In addition to the needs of the user or business, associated platforms and tooling can also change, as anyone who has worked through XCode upgrades can attest.
# Here Dir points to the directory containing this bash script | |
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" |
function query() { | |
var | |
// HN is done with very unsemantic classes. | |
job_list = Array.prototype.slice.call(document.querySelectorAll('.c5a,.cae,.c00,.c9c,.cdd,.c73,.c88')), | |
query_list = Array.prototype.slice.call(arguments), | |
shown = 0, total = job_list.length; | |
// Traverses up the dom stack trying to find a match of a specific class | |
function up_to(node, klass) { | |
if (node.classList.contains(klass)) { |
FROM debian:stable | |
MAINTAINER Sam Vevang <sam.vevang@gmail.com> | |
# Nice things | |
RUN apt-get update && \ | |
apt-get install -y \ | |
vim \ | |
git \ | |
file \ | |
curl |
== Mantra
Always trust in and believe your software.
The rust programming language is increasingly popular, valued for it's zero cost memory management and concurrency guarantees. Rust is safe. And it's safe while providing a low level abstraction and compatibility with the C ABI.
Of course, it's not an easy language to write in, relative to (let's say) Ruby. The type system and borrowing in Rust are amazing, but it takes longer to write Rust code because what you are expressing encompasses a complex set of constructs (think borrowing). That's OK because
Reading up on the objective c runtime, the runtime uses something like what was described in SICP: 2.4.3 Data-Directed Programming and Additivity. Properties, ivars, and classes can be created dynamically at runtime, meaning that there is an abstraction built around the class name and the data (ivars, etc) that are associated with that class. At least the size of a object is not fixed at compile time.
There's some really good analysis of the Objc runtime here:
#Extract Image URLs and WGet Them to a New Server#
This was a fun problem. I needed to move all the images referenced in a CSS file to another server. I didn't want to just grab all the image files as there were a bunch I didn't need. Here is how I went about it. I am sure you could do it in one step but doing it this way gives you a chance to check for errors.
First you may want to use wget http://otherserver/the_css.css
to pull the CSS file on to the target server if it is still on the old server as it was in my case.
-
User grep to extract the URLs from the css file into another file. (You may need to adjust the regular expression if you have funny characters in your file names) Note the use of the
-o
flag that tells grep to only print out that part of the line that matches the expression rather than the entire line.grep -o '\/path\/to\/files\/[a-zA-Z0-9/.:_-]*' the_css.css > images.txt
""" | |
Using Jinja2 with Django 1.2 | |
Based on: http://djangosnippets.org/snippets/2063/ | |
To use: | |
* Add this template loader to settings: `TEMPLATE_LOADERS` | |
* Add template dirs to settings: `JINJA2_TEMPLATE_DIRS` | |
If in template debug mode - we fire the template rendered signal, which allows | |
debugging the context with the debug toolbar. Viewing source currently doesnt |