投稿者「sasaki」のアーカイブ

[PHP] 配列の内部ポインタ(カーソル)の操作

概要

PHPの配列は内部ポインタ(カーソル)を持っており、配列内で現在参照している要素をシフトすることができるらしい。適当にコードを書きながら色々試してみたので整理する。

current関数

current関数は、指定した配列の内部ポインタが指している要素を戻す。ポインタ自体は動かさないので連続で呼び出しても結果は変わらない。最初は先頭の要素を示している。

$array = ['a', 'b', 'c'];
echo current($array); // a
echo current($array); // a
echo current($array); // a

next関数

next関数は、内部ポインタを一つ進めて、進めたあとに指し示している要素を戻す。これ以上進めない(=末尾要素を指している)場合はfalseを戻す。

$array = ['a', 'b', 'c'];
echo next($array); // b
echo next($array); // c
echo next($array); // false

prev関数

prev関数は、next関数の逆で、ポインタを一つ前に移動する。これ以上戻れない(=戦闘要素を指している)場合はfalseを戻す

$array = ['a', 'b', 'c'];
echo next($array); // b
echo next($array); // c

echo prev($array); // b
echo prev($array); // a
echo prev($array); // false

reset関数

内部ポインタを先頭に移動し、先頭要素を戻す

$array = ['a', 'b', 'c'];
echo next($array); // b
echo next($array); // c

echo reset($array); // a

end関数

内部ポインタを末尾に移動し、末尾要素を戻す

$array = ['a', 'b', 'c'];
echo current($array); // a
echo end($array);     // c

each関数

each関数は、現在内部ポインタが指し示している要素のキーと値のペアを戻し、内部ポインタを次に進める。
キーは[0]または[‘key’]で、値は[1]または[‘key’]で参照できる。

$array = ['a', 'b', 'c'];

var_dump(each($array)); // [0 => 0, 1 => 'a', 'key' => 0, 'value' => 'a']
var_dump(each($brrby)); // [0 => 1, 1 => 'b', 'key' => 1, 'vblue' => 'b']
var_dump(each($crrcy)); // [0 => 2, 1 => 'c', 'key' => 2, 'vclue' => 'c']
var_dump(each($array)); // false

この関数は PHP 7.2.0 で 非推奨になります。この関数に頼らないことを強く推奨します。

具体例

全然使いみちが思いつかないけど強引に使ってみた。

$user_age = [
  'Taro'   => 25,
  'Jiro'   => 19,
  'Hanako' => 14
];

while ($user = each($user_age)) {
  echo $user['key'] . 'is' . $user['value'] . "\n";
}
$ php hoge.php
Tarois25
Jirois19
Hanakois14

言うまでもなく、上記コードはforeachとかで書き直せる。

所感

直接使うことはまず無いけど、PHPの配列が内部的にこうやって動いてるということを想像するとどこかで役立つかも?

3年目プログラマが参考にしたQiita記事まとめ⑭

概要

特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ14本目

Qiitaまとめシリーズ

有名私立大学のホームページを計測してみた

龍谷大学の描画速度がスゴイ。それなりにコンテンツが充実しててリッチなのにこの早さはかなり工夫されてる。対して学習院は同じぐらいの情報量なのに描画に時間がかかりすぎてる。フロントエンジニアの技術力の差が出てる感じがする。

削除したツイートだけ取ってくるシステムを作ってみた

こういうの何度か作ってみようとか思ったけど、どうやら削除済みツイートを意図的に見ようとすることが規約違反になるみたい。そりゃないよ。

白っぽい文字(白,臼,日,曰,目,且,旦,亘)で動くプログラミング言語を作った

一度BrainFuckライク言語を作ってみたい。最小限のプログラミング言語の動きが学べるし、C言語で十数行で実装できるみたいだし。

(Twitterとかに)zipファイルを(画像ファイルに変換して)アップロードできるツールをつくりました

なかなかに興味深かった。デジタルだとどうしてもソレが画像であることを証明できないから必ずこういう抜け道はあるよね。

【Git】オレならこう説明する!Git初心者への用語説明

わかりやすいっちゃわかりやすいけど正確さに欠ける。まぁ最初は正確さより雰囲気に慣れることが大事だと思うけど。関係ないけどQiitaでソースツリー使ってる記事初めてみたかも。個人的には早い段階でソースツリーは脱却して欲しい。

受託でやるのに程よいベストなGitのフローを考える

とりあえずmasterを自由に更新できるのは辞めたい。masterは常にそれを本番に適用しても構わないという前提に、レビュー環境に適用するためのreleseブランチと、問題解決ごとのトピックブランチを切るようにしたい。と書いてて気づいたけどこれほぼgit-flowだ。

CSSだけでaタグのリンク先プレビューを表示する

なるほどなぁと唸る感じ。シンプルながらかなり強力そう。というかcontent属性で直接リソース指定できるのがビビる。文字列入れてそれ表示する程度のものだと思ってた。

リモートワークを始めて1年が経過し、幸福だったこと・苦痛だったこと・より幸福になるために

一長一短あるのはよくわかるけど、それでも自分はリモートワークに適してると思った。
記事中の各デメリットについて

  • 人間関係及びコミュニケーションの問題
    — 表情が見えない問題についてはSkypeなりでビデオ会議すればいい話
  • 生産性の問題
    — 日頃からやってるBacklogの自動化による実働管理を続ければ実体は変わらないと思うし
  • 精神的な問題
    — 出勤しててもそんな変わらない
  • 稼働時間の問題
    — Backlogの自動化で解決できる
  • 人生設計の問題
    — 既に嫁が居て外出も多いから問題ない。

デメリット全部問題なかった。

有志の社内勉強会を1年で50回くらいやった結果 伝えたいこと

小規模、低レベルな勉強会を運営する側に回るっててもあるのか。
何となく勉強会って講義形式か、ハンズオン形式だと思ってたからディスカッション形式なるものがあるのが意外。というか記事主的にはそれがほとんどらしい。あんまりイメージできないな。「タスク管理について」でディスカッションとか無事に進行できるのか。

人は自分が知らない物を激しく批判し、排除しようとする

極論気味だけど言いたいことはわかる。けど遠回しにこの記事もPHP批判してるようにみえるぞ。

3年目プログラマが参考にしたQiita記事まとめ⑬

概要

特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ13本目

Qiitaまとめシリーズ

怠惰なFizzBuzzが面白かったので自分も怠惰なFizzBuzz書いてみた

Rubyの機能をよく活用したFizzBuzzの例。最初に記事を見た時は意味不明だったけど、落ち着いて紐解いていったら凄く勉強になった。
特にlazyによる遅延評価はよく理解してなかったので、無限リストから効果的にfizzbuzを出力できるこの例に感動。

いまみているウェブページを阿部寛のサイトっぽくするChrome拡張を作った

阿部寛の何がエンジニアをここまで駆り立てるのか

もし、HTMLのテキスト周りでデザイナーからこんなお願いをされたら…

デザインだけ与えられてこれそのままHTMLで再現してとか無茶ぶりされた時に役立ちそうなTips

機械学習案件を納品するのは、そんなに簡単な話じゃないから気をつけて

機械学習案件の納品がどこまでを指すのか、特にエンジニアと非エンジニアの間で認識の差が発生しちゃう分野だと思う。といっても流石に運用試してない学習モデルだけ納品っていうのは無いだろとは思うけど。

HTMLとJavaScriptだけでBLE通信できるのか?

スゴイ。Webでハードウェア制御が容易に出来る様になるってことだ。夢が広がる。セキュリティの心配はありそう。

Webセキュリティ覚書 : “攻撃” 編 [ 初学者向け ]

内容はありがちだけど、具体例がしっかり書かれてるのは教材としては良い。単純な技術的好奇心でクラッキングはやってみたいなと思う。合法的に。

[ まつもとゆきひろ氏 ]若手エンジニアの生存戦略

やっぱりまつもとゆきひろの思想は好き。書籍化されてないこういう発言がまとめられてると助かる。

Laravelのディレクトリ構造と、お役立ちTips

最近はLaravelを使うことが増えてきてるので、流し見だけでも、この辺を知ってるか知らないかで大きく違いそう。

Chrome 63以降で使えるJavaScriptのdynamic import(動的読み込み)

これが普及してくれると、webpackでbundleされたSPAの初回起動時ローディングに時間かかる問題を解決できる‥‥?ブラウザレベルで遅延ロードは早いうちに対応してほしかったなぁ。

関数宣言 vs 関数式 | ES2015+ by

記事で書かれてるような具体的なメリット/デメリットまであまり意識したことはなかったけど、個人的にはconstでfunction式を代入してexportする以下のスタイルが一番好き。

export const func = function() {
}

もちろん関数内で利用するクロージャとかコールバックにはアロー関数を使う。関数宣言だと巻き上げでよくわかんないことになるし、アロー関数使わないとthisを使いまわせなく辛いし。

fetch().then((response) => hogehoge)

Web+DB vol.102 ペアプロ/モブプロ特集を読んだ

概要

Web+DB vol.102の特集がペアプログラミング・モブプログラミングで、個人的に興味があるのにやったことが無い分野だったので衝動買い。将来的にペアプログラミング、モブプログラミングを業務で行う機会があったらふりかえれるように、ざっくりとその要約と所感をまとめる。

以降は個人的に勉強になった点のみ抜き出しており、特集内を網羅的にまとめているわけではないので注意。

前提

理系卒Web系プログラマ3年目。
ペアプログラミングはそれなりに知ってるけど実務での経験無し。
モブプログラミングは言葉と概要程度は知ってるが経験無し。

ペアプログラミングってなんだ

  • ペアプログラミングは二人ペアでプログラミングを行うこと
  • コーディングに限らず、「目標定義」「タスク分割」「設計」「コーディング」「リリース」までの全ての作業をペアで行う
  • 主にPCを操作する「ドライバ」と、それを補助する「ナビゲーター」に分かれる。役割は定期的に交代する

モブプログラミングってなんだ

  • ペアプログラミングを大勢で行うように拡張したもの
  • 「ドライバ」は引き続き一人、残り全員が「ナビゲーター」となる
  • モブの人数は3〜5人が最適らしい

ペアプロ/モブプロで得られる効果はなんだ

  • ペア内、モブ内の情報伝達効率を最大化すること
  • 作業への集中度を高め、作業の質を向上させること
  • 楽しくチームビルディングすること

ペア/モブで行うメリット

  • ドライバがコードを書いてるそばから、ナビゲーターがそのコードをリアルタイムにレビューすることができるので、コーディングからレビューまでのスパンを最短にできる
  • コードを書いてしばらくしてから指摘を受けるよりも精神的な苦痛が少ない(?)
  • 現在の作業内容を声に出して会話することで、思考が整理され、プログラミングの質が向上する
  • ナビゲータはドライバよりやや引いた視点で見ることができるので、ドライバが気づきにくいバグやミスに気づける
  • ペア/モブ内で情報を共有できるので、属人性の問題を軽減できる

ペアプログラミングの進め方

  • コードを書く前に方向付けをしよう
    — 最終目標はどこか、いつまで行うかなど
  • コードを書きながら会話し、考えを共有する
    — 言葉にして相手に伝えることこそ最大の思考整理法
  • ロールを交代する
    — 必ず定期的に交代する。交代タイミングは時間でも作業単位でも可

ペアプログラミングはいつ行うのがベストか

  • チームに新メンバーが入ってきたとき
  • デバッグや不具合修正を行うとき
  • 長時間の改修作業になるとき

ペアプロは誰とペアを組むか

  • ベテランと新人
    — ペアプログラミングによる教育は最強の教育法
  • ベテラン同士のペア
    — 最も品質の高い開発を行う方法
  • 新人同士
    — 敷居が高く生産性は望めないが、コミュニケーションは促進できそう

モブプログラミングの特徴など

  • ドライバの作業を複数のナビゲータがみんなで力をあわせて補助する
  • 並行作業を行わずに、モブ全体で課題を一つ一つこなしていく
  • モブ内だけで全ての問題を解決できるようなチームづくりをする
  • 困難にみんなでハマって、成功もみんなで喜ぶ
  • 非エンジニアにもモブに入ってもらって、エンジニアがどんなことをしているのかを肌で感じてもらう

所感

ペアプログラミングはレビューをリアルタイムで行うためにペアでプログラミングをするもの。モブプログラミングはペアプログラミングを多人数に拡張したもの。

ということは、ペアプログラミングをするにしても、モブプログラミングをするにしてもコードレビューの文化がしっかり根付いていないの難しいのかなと思った。

他人のコードを読んで、それに対して意見が言える人でないとナビゲータは難しいのかなと思う。そう考えると簡単にペアプログラミング、モブプログラミングを業務で導入するのはハードルが高そうだ。まずはコードレビューの文化から育てていかなければならなそう。

[Node] Node.jsでチャットワーク(chatwork)にメッセージを送信する

概要

Node.jsを用いてチャットワーク(chatwork)にメッセージを送信するTips。
メッセージを送信する最短Tipsで、それに特化したモジュールを使うので、メッセージの取得やタスクの作成など、チャットワークAPIでできる様々なことは本記事では取り扱わない。

関連記事

前提

以下環境で動作確認済み

debian 8.6
node 5.1.2
npm 3.8.6
post-chatwork-message

APIキーの用意

チャットワークにログイン後、API設定からAPIトークンを取得して控えておく

メッセージを送信するルームのIDの用意

メッセージを送信するルームのIDを用意する。送信可能なのは自信が参加しているルームのみ。IDは対象のルームを開いた際のURLから確認することができる。

URLが

https://www.chatwork.com/#!rid1234567

の場合、1234567がルームIDになる。

メッセージ送信用ライブラリをインストール

グローバルインストールでもかまわないが、post-chatwork-messageをnpmでインストールする。名前の通りチャットワークにメッセージをPOSTすることに特化したモジュール。

$ npm install --save post-chatwork-message

コード例

index.js

const postChatworkMessage = require('post-chatwork-message')
const CHATWORK_API_KEY = '67a568hogehogehogea1898871e9193'
const roomId = '1234567'

postChatworkMessage(CHATWORK_API_KEY, roomId, 'Hello, World')

実行例

$ node index.js

のようになる。

[Docker] Ubuntuのコンテナ内で日本語入力ができない

Dockerで構築したUbuntuの環境でbashを動かした際に、日本語が入力できなかったのでその解決策の備忘録。
題に反してDockerに限らずDebian系全般の問題だと思う。

$ apt-get update
$ apt-get install -y language-pack-ja-base language-pack-ja
$ echo "export LANG=ja_JP.UTF-8" >> ~/.bashrc

で、bashrcを再読込すれば日本語が入力できるようになる。

$ source ~/.bashrc