ossa-ma

---

name: the writing whip description: >- Kill all AI writing tropes and behaviours at the source: generation. Focus on quelling behaviour-driven triggers. Load before writing, especially for anything longer than a paragraph and re-check output against it, extremely important for communications, documentation, outbound, client-facing copy and for your own replies to the user. metadata: category: writing author: Ossama Chaib

D2theR

Why?

I got sick of writing the same Serializer & ModelViewSet classes over and over so I found and wrote some code to do it for me, and somehow it works! Please note that there are a lot of caveats to running an API like this and while this may work, I know there's A LOT of room for improvement, feel free to fork and help!

USAGE

Import the router module to your main sites urls.py file as the injection point like so... Make sure to remove any other imports from other viewsets that you don't need that may conflict!

timlo

// https://github.com/settings/replies
// Settings > Saved Replies
// Execute in JS console.
(async function generateReplies(document) {
  // https://conventionalcomments.org/#labels
  const LABEL = {
    praise: "praise",
    nitpick: "nitpick",
    suggestion: "suggestion",
    issue: "issue",

ifyoumakeit

(async function generateReplies(document) {
  // https://conventionalcomments.org/#labels
  const LABEL = {
    praise: "praise",
    nitpick: "nitpick",
    suggestion: "suggestion",
    issue: "issue",
    todo: "todo",
    question: "question",
    thought: "thought",

Daenyth

import requests
import logging
import httplib

# Debug logging
httplib.HTTPConnection.debuglevel = 1
logging.basicConfig()
logging.getLogger().setLevel(logging.DEBUG)
req_log = logging.getLogger('requests.packages.urllib3')
req_log.setLevel(logging.DEBUG)

PurpleBooth

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

kky

#!/bin/sh

echo "What should the Application be called (no spaces allowed e.g. GCal)?"
read inputline
name=$inputline

echo "What is the url (e.g. https://www.google.com/calendar/render)?"
read inputline
url=$inputline

gane5h

"""
Custom parser for nginx log suitable for use by Datadog 'dogstreams'.
To use, add to datadog.conf as follows:
    dogstreams: [path to ngnix log (e.g: "/var/log/nginx/access.log"]:[path to this python script (e.g "/usr/share/datadog/agent/dogstream/nginx.py")]:[name of parsing method of this file ("parse")]
so, an example line would be:
    dogstreams: /var/log/nginx/access.log:/usr/share/datadog/agent/dogstream/nginx.py:parse
Log of nginx should be defined like that:
    log_format time_log '$time_local "$request" S=$status $bytes_sent T=$request_time R=$http_x_forwarded_for';
when starting dd-agent, you can find the collector.log and check if the dogstream initialized successfully
    """

jedi4ever

@datadoghq - Overall well done! Here's some feedback:

Signup/User process

• when someone invites you to their datadog/team, you get an email but because you are already registered you can't join their team. Especially annoying for freelancers that work for multiple customers but don't have an email account at the customer site
• disable a user is scary (will this delete it, can I re-create it?); a warning or ? next to it would help for fast understanding
• if the user you invite does not have it's gmail activated yet (google for apps), when the email is added it's send out (but doesn't reach it of course). There is no way of re-sending the invite from the admin side
• the forcing of registering at least one agent/integration is really annoying. if you signup through an ipad or the person signing up (like billing) does not have any way to go past that screen. So you wonder , am I registered or not? In our case the person installed the mac agent from it's laptop to get it going. No need for that imho
• when

fnichol

Format Changes to Test Kitchen's kitchen.yml File

This is happening thanks to a refactoring of the data manipulation code formerly in Kitchen::Config.

There are now 3 main configuration blocks that can be placed in the various levels:

• driver: Configurtation relavent to Kitchen drivers. This is a combination of what was driver_plugin and driver_config. Backwards compatability is guarenteed with the legacy formats for a time, then will be deprecated (with a warning when encountered), then will be removed in a future release.
• provisioner: Configuration relating to the automation tool being used. Currently supporting "chef_solo" and "chef_zero". Previously several Chef-related config paths were dumped in a Suite block, namely data_path, data_bags_path, environments_path, nodes_path, roles_path, etc. These will be supported for backwards compatability, then will be deprecated (with a warning when encountered), then will be removed in a future release.
• busser: Configuration rela