Nested checkbox rendering would be nice (view the sourcer for this gist)
- Task 1
- Task 2
- Subtask a
- Subtask b
- Task 3
There's no need to complete parents when child nodes are all checked.
| from django.views.generic.base import View, TemplateResponseMixin | |
| from django.views.generic.edit import FormMixin, ProcessFormView | |
| class MultipleFormsMixin(FormMixin): | |
| """ | |
| A mixin that provides a way to show and handle several forms in a | |
| request. | |
| """ | |
| form_classes = {} # set the form classes as a mapping |
| #-*- coding: utf-8 -*- | |
| import urlparse | |
| from django.contrib.auth import REDIRECT_FIELD_NAME, login | |
| from django.contrib.auth.forms import AuthenticationForm | |
| from django.http import HttpResponseRedirect | |
| from django.utils.decorators import method_decorator | |
| from django.views.decorators.cache import never_cache | |
| from django.views.decorators.csrf import csrf_protect | |
| from django.views.generic.edit import FormView | |
| from django.conf import settings |
| <!-- using the truncate filter --> | |
| {% for post in site.posts limit:10 %} | |
| <h2><a href="{{ post.url }}">{{ post.title }}</a></h2> | |
| <span class="post-date">{{ post.date | date: "%B %d, %Y" }}</span> | |
| {% if post.content.size > 2000 %} | |
| {{ post.content | truncatewords: 300 }} <!-- bad! content gives you rendered html and you will truncate in the middle of a node --> | |
| <a href="{{ post.url }}">read more</a> | |
| {% else %} | |
| {{ post.content }} | |
| {% endif %} |
| # Committing changes to a repo via the Github API is not entirely trivial. | |
| # The five-step process is outlined here: | |
| # http://developer.github.com/v3/git/ | |
| # | |
| # Matt Swanson wrote a blog post translating the above steps into actual API calls: | |
| # http://swanson.github.com/blog/2011/07/23/digging-around-the-github-api-take-2.html | |
| # | |
| # I was not able to find sample code for actually doing this in Ruby, | |
| # either via the HTTP API or any of the gems that wrap the API. | |
| # So in the hopes it will help others, here is a simple function to |
| # get into the master branch | |
| git checkout master | |
| # create a new branch for the changes and check it out | |
| git checkout -b dev_branch | |
| # stash the changes until we revert master | |
| git stash | |
| # go back to master |
| #include <iostream> | |
| #include <cstdlib> | |
| class Node | |
| { | |
| public: | |
| Node* next; | |
| int data; | |
| }; |
| /* | |
| * Console Color | |
| * | |
| * Copyright (c) 2005 Joergen Ibsen | |
| * | |
| * 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 |
Nested checkbox rendering would be nice (view the sourcer for this gist)
There's no need to complete parents when child nodes are all checked.
When working with Git, there are two prevailing workflows are Git workflow and feature branches. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited, and the focus of this article.
If you are new to Git and Git-workflows, I suggest reading the atlassian.com Git Workflow article in addition to this as there is more detail there than presented here.
I admit, using Bash in the command line with the standard configuration leaves a bit to be desired when it comes to awareness of state. A tool that I suggest using follows these instructions on setting up GIT Bash autocompletion. This tool will assist you to better visualize the state of a branc