bradmontgomery

#!/usr/bin/env python
"""
Very simple HTTP server in python (Updated for Python 3.7)

Usage:

    ./dummy-web-server.py -h
    ./dummy-web-server.py -l localhost -p 8000

Send a GET request:

elmarcoh

$('#participantes-table').dataTable({
	bProcessing: true,
	bServerSIde: true,
	sAjaxSource: "/path/to/your/tastypie/api/list/objects/?format=json",
	sAjaxDataProp: "objects",
	aoColumns: [
		// Put the resource name that corresponds to each table column
		{'mData': "your"},
		{'mData': "columns"},
	],

vshjxyz

@orders_table = $('#orders-table', element).dataTable
    bProcessing: true
    bServerSide: true
    sAjaxSource: ORDERFULL_API
    sAjaxDataProp: "objects"
    aoColumns: [
        # Put the resource name that corresponds to each table column
        {
            "mData": "id"
            "sClass": "order-id"

rxaviers

People

:bowtie:	😄 :smile:	😆 :laughing:
😊 :blush:	😃 :smiley:	☺️ :relaxed:
😏 :smirk:	😍 :heart_eyes:	😘 :kissing_heart:
😚 :kissing_closed_eyes:	😳 :flushed:	😌 :relieved:
😆 :satisfied:	😁 :grin:	😉 :wink:
😜 :stuck_out_tongue_winking_eye:	😝 :stuck_out_tongue_closed_eyes:	😀 :grinning:
😗 :kissing:	😙 :kissing_smiling_eyes:	😛 :stuck_out_tongue:

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

denji

Moved to git repository: https://github.com/denji/golang-tls

Generate private key (.key)

# Key considerations for algorithm "RSA" ≥ 2048-bit
openssl genrsa -out server.key 2048

# Key considerations for algorithm "ECDSA" ≥ secp384r1
# List ECDSA the supported curves (openssl ecparam -list_curves)

biomorgoth

class FieldSelectMixin(object):
    """
    Mixin to allow field selection.
    This has to be done in two parts:
    1) In model queryset for database selection. This need to be in some code section
    where the queryset is ready, but still not evaluated. obj_get_list and obj_get are perfect
    for Tastypie GET requests.
    2) In full_dehydrate method, to prevent from Tastypie fetching all the fields from the model.
    """
    def full_dehydrate(self, bundle, for_list=False):

beardedeagle

###################################################################
# mixin that utilizes dehydrate to implement field selection      #
# Tested with python 2.7.5, django 1.8 and django-tastypie 0.12.1 #
###################################################################
class fieldSelectMixin(object):
    """
    Mixin to allow field selection, dehydrate method.
    """
    def dehydrate(self, bundle):
        selectedFields = bundle.request.GET.get('fields')

gbin

from errbot import BotPlugin, botcmd

class PluginMaker(BotPlugin):
    """ Example demonstrating how to create an errbot plugin out of thin air.
    This basically generates a plugin from scratch and registers it at activation.
    """

    def activate(self):
        super().activate()

citrusui

How do I dropdown?

This is how you dropdown.

<details>
<summary>How do I dropdown?</summary>
<br>
This is how you dropdown.