テキストチャット中心の開発コミュニケーションと課題感 ご飯ブログを書いてばかりで、老害活動できていないからたまには真っ当なブログ。 最近、テキストチャットを使ったコミュニケーションが円滑になるためには？という課題についてよく考えるのでチャットユーザの民度を上げるための覚え書きをまとめます。 Slackなどを使ったチャットコミニュケーションの民度、運用の成熟に思いを馳せてる。 — あほむ (@ahomu) June 28, 2016 オフィスワーカーにとってのチャット オフィスワーカーであっても、メールと同じで記録が残りメールよりも即時性が高い、チャットによるコミュニケーションは少なくありません。物理的に移動する手間を省き、送信側の任意のタイミングでメッセージを送れることなどが魅力です。 口頭コミュニケーションは即時性が高い代わりに揮発性も高く、その場に居合わせないと得られない情報です。口頭

コードレビューにstashを使ってます。 こいつはgitのブランチ間の差分に対してコメントをつけることができるツールです。 ただ、ネットを介したコミュニケーションって何故か気が大きくなってしまったり、感情が見えづらかったりで誤解を生みがちです。 特にコードレビューって間違いを指摘するとかあんまり楽しい会話をするわけでもないので、言葉には気を使わないといけません。 今日は自分が気をつけている言葉や行いを上げてみます。 否定しない def get_name(name) @user.find(name: name) end ☓：getは軽量なアクセッサとして使うのが常識なのでやめて下さい。 ◯：findしてることが分かるメソッド名が良いです いちいち否定する必要はないです。素直にどうして欲しいか書きましょう。 否定しない2 「けど〜」 def search(name) @user.find(na

6月25日(土)に、秋葉原・通運会館にて開催された「技術書典」に行ってきました。このイベントは、ITエンジニアなら誰でもお世話になるであろう「技術書」をテーマとする「技術書オンリーイベント」で、今回が初開催であるばかりか、おそらく業界でも初ではないかと思われる新しい試みです。 （上記写真は技術書典の会場となった通運会館） 会場にはIT系出版社から技術コミュニティまでの多種多様な出展サークルと、それらが頒布する書籍や冊子を買い求めるたくさんの来場者が集まりました。1日で約1400人が来場したという、熱量の高いイベントの模様をお伝えします！ 技術書典の主旨と内容 技術書典のWebサイトに、イベントの主旨が説明されていますので引用します。 技術書典とは、新しい技術に出会えるお祭りです。技術書典は、いろんな技術の普及を手伝いたいとの想いではじまりました。技術書を中心として出展者はノウハウを詰め込み

おはこんばんちは!! 尾藤 a.k.a. BTOでっす UUUM では僭越ながら CTO をさせてもらってマッスル。 なので UUUM でのエンジニアの面接は僕がやっているんですが、面接の時に気をつけていること、やっていることをご紹介したいと思います。 最初に会社の紹介をする 何はなくともまずはこれ。 転職活動中の方に、UUUM を選んでもらわなければ来てもらえません。 特に UUUM は YouTuber のプロダクションとしてのイメージが強く、エンジニアには馴染みがありません。 システム開発や、新規事業の立ち上げをしていることも知らない方が多いかなと思います。 なので、最初に会社に紹介をして、UUUM に入社することの魅力を感じてもらう努力をします。 実は最初の頃は技術面接をメインにやってて、会社の紹介をあまりやってこなかったために、最終選考に残るものの、最終的に別会社に転職されるケー

2011年に主に書いた「ソフトウェア開発組織が持つべきカルチャー」を表にしてみました。評価列は、みなさんの組織ではどうかを振り返って記入してみてください。 ソフトウェア開発組織が持つカルチャーが、個々のソフトウェアエンジニアに大きな影響を与えるということで、一連の記事を書きますとした「まえがき」に相当するのが次の記事です。

「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン

r.c.oは”色のプロ”に向けた無料の色当てスマートフォンアプリ「r.color」の提供を開始。「プロ向け」のうたい文句通り、かなりの高難易度ゲームとなっています。 プロ向けゲーム 「r.color」では、文字と同じ色を当てる「MATCHING」からスタートし、50点以上を取ると他のゲームが遊べるようになる仕組み。「MATCHING」の他にも、正しい色相環を作る「WHEEL」、正しいグラデーションを作る「GRADATION」、写真に対する明度・彩度の加工を見極める「VARIANCE」など7種類（Android版は「VARIANCE」を除く6種類）のゲームが楽しめます。 「MATCHING」の画面。難しすぎる 「色のプロであれば全てのゲームで80点以上出せるかもしれない、しかしそうでない方は50点・60点どまりでしょう」「本当に色を見る力がずばぬけている方なら、100点を超えることも可能」と

ハンドメイド作品の販売サイト「Etsy」にある、鉛筆を使った彫刻作品が秀逸です。木製の軸をトンネルの形に、さらにその中の芯をSLの形に彫り上げ、トンネルから列車が出てくるシーンを表現。精巧さ・アイデアともに素晴らしい作品となっています。 鉛筆が、トンネルから出てくるSLに……！（「Etsy」販売ページより） 製作したのは米国在住のアーティスト・CindyChinnさん。使用している鉛筆の太さは直径約1.5センチ。さらに細いはずの芯を削って、SL、その下のレールまでも再現しており、その器用さに驚かされます。外側の軸をトンネルや橋に見立てるなど、鉛筆の構造を上手く生かしているのもポイント。 まさに超絶技巧 価格は4万2553円（税込）、残念ながら米国外への発送は不可。ほかにもハンマーを握った手やノコギリを持った手など、さまざまな鉛筆の彫刻作品をEtsyで販売しています。 ほかにもハンマーを握っ

数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM

Photo by Michelle Hofstrand こんにちは。谷口です。 paizaを開発しているエンジニアの中には、もともとSIerで開発をしていた人が何人かいます。 paizaで転職のご相談をいただく方の中にも、SIerからWeb系に転向したいという方は増えていますが、Web系の経験のない人が勉強などを何もしないまま転向を叶えるのは正直難しいです。しかし、Web系の開発業務経験のない人は「具体的に何をどう勉強をしたら役に立つのかわからない…」という人が大半かと思います。 というわけで今回は、SIerからWebサービスを開発している弊社へ移ったエンジニアたちが今になって思う、「転職前にやっておいてよかったこと」、また今になって「やっておけばよかった！」と思うことを聞いてみたのでご紹介します。 いずれは転職を考えているという人、転職はまだ考えてないけどWeb開発の勉強に興味があるとい

人工知能が書いた特許願を日本の特許庁が受理しました。ちゃんと出願番号もらえました。これは世界初だと思う。たぶん。 そのうち、人工知能が自動的に特許を書いて、自動的にＩＰＤＬにアクセスして重複特許かどうかチェックして、自動的に一日65536回くらいオンライン出願して、特許が人工知能で作ったものばかりになる日が来るのかもしれない。特許庁の職員と回線がその速度で対応できないと思うけど。 ちなみに上記の写真の整理番号はAI-PATENT（人工知能特許)という意味で、最後の４桁の数字はunixtimeを9999で除算した剰余だ。内容は請求項の自動文書生成についての特許だ。 いろいろ書きたいけれど、最近、なんか色々、文書をかいたりまとめたり、綿密なコードを書くのがしんどい。これが老いというものか。 先月、会津大学に行って講演する機会があった。講演まで時間が余ってて、五十嵐くんという自然言語処理をやって

背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること

HTML5でグラフを描く方法は幾つかあります。一つはCanvasを使った方法です。これは高度なグラフィックスが描ける一方、JavaScriptなどからインタラクティブに扱うのは複雑になっています。 そこで今回はSVGを使ったグラフライブラリを紹介します。SVGはXMLベースで軽量、かつJavaScriptとの親和性も高いものが多くなっています。 morris.js morris.jsは主に折れ線、棒、曲線、ドーナッツグラフをサポートしています。データをJSONで渡すだけで使えるので学習コストが低いのがメリットです。ライセンスは簡易BSD Licenseとなっています。 Chartist – Simple responsive charts Chartistはレスポンシブであることをメリットとしています。曲線、棒、円、ドーナッツグラフをサポートしています。ブラウザはIE9以降を対象としていま

SVG形式でウェブページのスクリーンショットを撮るChrome拡張機能「SVG Screenshot」をより便利に使うためのウェブアプリを Google App Engine で公開しました．SVG Screenshotのコンセプトについては以下の記事をご覧ください． この記事では ウェブアプリでできること Chrome拡張機能とウェブアプリの融合（撮影したファイルをウェブアプリにアップロードして保存する機能） について，順に紹介します． ウェブアプリでできること スクリーンショットファイルを表示する https://svgscreenshot.appspot.com/viewer にアクセスすると，これまで拡張機能に付属していたものと同様なビューワページが開きます．拡張機能で生成されたスクリーンショットSVGファイルを，中央の白い領域にドラッグ・アンド・ドロップすると内容を表示できます．

――　今回のプログラムでは、「スマホの乗っ取りが可能かどうか」「パーミッション（許可）を取得しているもの以外の情報取得が可能か」「『Moplus SDK』が使用されているか」という3つの項目をチェックしています。これがSimejiに対して持たれている懸念なのでしょうか。 高橋氏　SNSなどに投稿されている代表的な懸念や不安に向き合いたいと思いました。「乗っ取られる」という表現は技術的な概念として正確性を欠いていますが、ユーザーの漠然とした不安を解消できなければ意味がありませんので、あえてそのままの日常的な言葉で依頼をしました。 小西氏　「Simejiが悪さをするのではないか？」という懸念をなくしたい、という思いが強く出ていると感じました。そういえば先日もネット上で話題になっていましたが……。 ――　Baidu IMEとSimejiに関する「はてな」のブログ記事を削除するよう申立てた件ですね

皆様、はじめまして！DMM.com Labo システム本部 事業サービス開発部の久野です。この度、社内の勉強会のLTで話した内容をまとめてみました！ 内容はWebGLというJavaScriptのAPIを使って、ブラウザ上で3Dモデルをアニメーション付きで描画するために何を行ったのか、です。 ▼実際に動作するデモです。 テクスチャを大量に読み込まなければならないので表示まで時間がかかるかもしれません。 ▲ブラウザによっては動作しない可能性がありますがデモプログラムなので悪しからず。 WebGLとはなんぞや？ WebGLとはKronos Groupが管理するOpenGL ES 2.0をブラウザ上のJavaScriptから扱えるようにしたAPIです。GPU(グラフィックカードまたはグラフィックボード)の機能を駆使して高度な3D描画を高速に行うことが出来、昨今のPC、スマートフォン等の主要なブラウ

はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1

どうも、セクションナイン の 吉田真吾（@yoshidashingo）です。 ウィーンからこんばんわ、WordCamp EUのContributor Dayのクロージングを聞きながら執筆しています。昨日までの炎天下に比べて10度近く気温が下がったおかげで快適に過ごせています。 今回6/24〜26にオーストリアのウィーンで開催されたWordCamp EUに参加しました。 2016.europe.wordcamp.org 経緯 もうひとつの目的 1. グローバルにモノを売るということ 何のサービスかわからない まずブースのぱっと見で何モノかわからない そしてサービスの説明が長い 象徴的なできごと：とある有名CEOからのアドバイス SaaSifyのスコープはプロダクト開発のみにかぎらない AMIMOTOの価値はなにか 顧客から見えるものを設計する Pantheon Flywheel Stacks