berkus

#![feature(result_map_or_else)]

extern crate serde; // 1.0.84
extern crate serde_derive; // 1.0.84
extern crate serde_json; // 1.0.34

use serde::Serialize;

#[derive(Debug, Serialize)]
#[serde(tag = "status", content = "result")]

berkus

1. Separation of immutable and mutable logic

Quite a lot of different people have been on the same trail of thought. Gary Bernhardt's formulation of a "functional core, imperative shell" seems to be the most voiced.

"Boundaries" - Gary Bernhardt

"Imperative shell" that wraps and uses your "functional core".. The result of this is that the shell has fewer paths, but more dependencies. The core contains no dependencies, but encapsulates the different logic paths. So we’re encapsulating dependencies on one side, and business logic on the other side. Or put another way, the way to figure out the separation is by doing as much as you can without mutation, and then encapsulating the mutation separately. Functional core — Many fast unit tests. Imperative shell — Few integration tests

https://www.youtube.com/watch?v=yTkzNHF6rMs

berkus

class utf8_text_view {

  const char *text;
  size_t bytes_count;
public:
  friend class iterator;
  class iterator {
    const utf8_text_view &parent;
    size_t offset;
  public:

berkus

// From https://pastebin.com/m8JMuTWz
extern crate pnet;
 
// use getopts::Options;
use std::env;
use std::net::{IpAddr, Ipv4Addr};
use std::str::FromStr;
use pnet::transport::TransportChannelType::Layer4;
use pnet::transport::TransportProtocol::Ipv4;
use pnet::transport::{transport_channel, ipv4_packet_iter};

berkus

class ClientListener : ChatClientListener {
  override fun onChannelSynchronizationChange(channel: Channel) {
    // Join channel first to trigger synchronization
    if (channel.status == Channel.SynchronizationStatus.ALL) { // Channel is fully synchronized
      channel.members // not null
    }
  }
}

chatClient.setListener(ClientListener())

berkus

#!/bin/bash
# Format data suitable for DataDog metric and submit it
data=$(system_profiler -xml SPBluetoothDataType 2>/dev/null \
| plutil -extract 0._items.0.device_title xml1 -o - - \
| plutil -convert json -o - - \
| jq -c --arg hostname $(hostname) --arg timestamp $(date +%s) 'map(to_entries[0])
| map (.key as $k | .value | select(.device_isconnected=="attrib_Yes" and .device_ispaired=="attrib_Yes")
| { battery: .device_batteryPercent, name: $k })
| map({metric: "battery.level", tags: [.name], host: $hostname, points:[[($timestamp|tonumber), (.battery|rtrimstr("%")|tonumber)]]})
| {series: .}')

berkus

Real World Specification

(aka "Algebraic JavaScript Specification")

This project specifies the behavior of a number of methods that may optionally be added to any object. The motivation behind this is to encourage greater code reuse. You can create functions that just rely on objects having implementations of the methods below, and in doing so you can make them work with a wide variety of different, but related data structures.

Definitions

For the purposes of this, spec, an "entity" is an object that has an [[equivalent]] operation (see bellow) and may implement some or all of the other methods.

berkus

// Usually these are added as private fields somewhere in Application class

    /**
     * Handle application foregrounding.
     */
    private final class LifecycleListener implements Application.ActivityLifecycleCallbacks {
        private Application application;

        LifecycleListener(Application app) {
            application = app;

berkus

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#ifdef _MSC_VER
#include <intrin.h> /* for rdtscp and clflush */
#pragma optimize("gt",on)
#else
#include <x86intrin.h> /* for rdtscp and clflush */
#endif

berkus

#include <ctime>
#include <iostream>
#include <string>
#include <experimental/net>

using net = std::experimental::net;
using net::ip::tcp;

std::string make_daytime_string() {
    using namespace std; // For time_t, time and ctime;