rinov

import os
import requests
import yaml
import json
import csv
import japanize_matplotlib  # For japanese font
import functools
import seaborn as sns
import datetime as dt
import pandas as pd

noto

これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。

概要

• 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。
• 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。
• グループ/チームでのミーティングを補完するためのものです。
  • みんなの前では話しづらい、込み入った内容を話します。
  • チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿っていません。
• 基本、「メンバーの時間」と捉えてください。メンバーが話したいこと、上長に質問したいこと、相談したいことを話す時間です。
• ですので、上長は相手の話をさえぎらず、聞くことに徹してください (話すのが得意な人、好きな人がマネージャになっている可能性が高いというバイアスに注意しましょうｗ)。

wasabeef

# .github/workflows/daily-ktlint.yml

name: Android CI (Ktlint)

on:
 schedule:
 # Daily 7am (JST)
 - cron: '00 22 * * *'

jobs:

michaelzengke

ADDS (Action Delegate Delegatee viewState) — A Kotlin Coroutines Based Android Architecture Pattern

Author: Michael Zeng

Contents

• Introduction
• Kotlin Coroutines Basics
• View State
• Action Worker

shyouhei

優秀なプログラマーになるためのコツ

重要な順で

優秀なプログラマーになるには非常に長い時間がかかるという現実を直視すべし

優秀なプログラマーというのは寝ている間に異世界に召喚されて無双するのとはわけが違うんですよ。

自分の例で言うとプログラミングを始めた中学生の時から優秀なプログラマだったかって、そんなわけない。みんなヘッポコからスタートしているに決まってるわけです。以来二十余年、地道に生き恥を晒し続けてきた結果として、現在いちおう業界の末席を汚すところまで来ている。このプロセスから目を背けるべきではないです。優秀なプログラマーに生まれる人間なんかいない。優秀なプログラマーに「育つ」んだし、それには時間が必要。今日から無双したいと思うな。

mizchi

思いつつままに書いてみたが、自分でもなんかしっくりこないので、WIP。同期縛りだからReduxのReducerがダメ、という自分の主張のコアの部分に自信がない。それを差し置いて呼んでほしい。

(1) https://togetter.com/li/911228 (2) http://qiita.com/mizchi/items/8cf4e0c868f5c49ebcbf

redux

いろいろあって仕方なく覚えることにした。今度こそ好きになれるかと思って勉強したが、無理そうな気配を感じている。これで3度目ぐらいの挫折。挫折、というか理解はしたと思う。理解をした上で好きになれない。まだ真の理解に至ってないという可能性はあるが…

昔勉強した際の、生JSの癖に関数合成を多用して見づらい、というのは FlowやTypeScriptの表現力でカバーできるようになったことで、ある程度解決したと思う。というかボイラープレートを超えると、それらはさして問題ではなかった。そこから先。

ryugoo

DroidKaigi day.2 - Fireside Chat

参加者

• 松山 さん
• @KeithYokomaku さん
• @konifar さん
• 藤崎 さん
• @operandoOS さん
• @mhidaka さん

gfx

最初期 - 開発人数: 1人, リリース前

このフェーズはほぼすべてのことが唯一の開発メンバーのスキルとマインド次第で決まるので、チームとしてできることは極めて少ないです。また、この段階のプロジェクトはリリース前に捨てる可能性もあるので、導入コストの高い開発ツールはまだ必要ありません。

• バージョン管理をしている
• リポジトリへのアクセス権を広げた（上長やチームメイト、開発基盤的な組織に権限を渡しておく）
• CIをセットアップし、最低限ビルドだけしている
• コーディングスタイルガイドを用意した
• （Androidの場合）.idea/codeStyleSettings.xml を用意してスタイルガイドに沿ってフォーマットできるようにした

andymatuschak

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

zaki50

package io.realm;

import java.io.IOException;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.util.EnumMap;
import java.util.Map;

public class RealmUtil {