Golang勉強会 in Kagawa http://gdgshikoku.connpass.com/event/26262/
Golang勉強会 in Kagawa http://gdgshikoku.connpass.com/event/26262/
Googleが先日「TensorFlow」という機械学習ライブラリを発表していて、話題になっています。 さっそく今日社内で紹介LTしてきました。 「社内」のエンジニアの話で言うと、機械学習の会社ではないので、機械学習とかDeep Learningとかには深掘りして話していないです。もちろん、機械学習ライブラリとかも知らない、けど、「なんかGoogleからディープラーニングをOSSで出したって話題になっているぞ」っていう感じの人向けに話しています。 TensorFlowをざっくりLTしてみた from Mitsuki Ogasawara 公式チュートリアルをちょっとだけ逸脱した線形回帰をやってみたサンプルもあります。 ちゃんと自動で微分できてます。 github.com このライブラリ、結構良いなあと思うのは、Googleが使っているという実績力かなと思います。公開初日に「Googleのプロ
クックパッド社の 朝Lint活動の記事を見て、最高じゃん…!と思い自分も真似して運用してみることにしました。 techlife.cookpad.com とりあえず自分だけで勝手にやることにしたので 「Lint警告解消に限らずやりたいこと好き勝手やってやるぞ!」って感じで2週間くらいやってみました。わりと進捗よくて成果出てきた気がするので、どう考えて何をやったかを残しておこうと思います。 なぜやろうと思ったのか 普段の開発タスクに追われて細かいところに手がつかず歯がゆい思いをしていたからです。 今作っているTaptripはグロースフェーズにあり、新規ユーザーの流入やDAU・MAUの向上といった数字から逆算した施策を高速にこなすべく開発を進めています。 この方針自体には納得しているんですけど、直近で数字が出るかよくわからない細かい改善というのはやはり優先度が低くなってしまうんですよね。そしてそ
YAPC::Asia Tokyo 2015 前夜祭に参加して、柴田さん( hsbt さん)とモリスさん*1( tagomoris さん)の講演を聴いた。特に最後のモリスさんの講演を聴いていて、ちょっとした衝撃を受けると共に、気づきや疑問もあったので、久しぶりに blog エントリを書こうという気になった。 なお、このエントリは講演メモや浮かんだ疑問、その後の議論等を記したものであり、すっきりとした結論は無いのでご注意。 モリスさんの講演 講演資料が公開されていた How to create/improve OSS products and its community from SATOSHI TAGOMORI 講演時に取ったメモがこちら 我々にできるOSSとそのコミュニティの育てかた ======================= id:tagomoris TD のモリスさん TD はデー
一般に会社員とは、昼間の決まった時間にオフィスに出勤して仕事をするものである。大勢の人が同じ時間と空間を共有することで、コミュニケーションを円滑にするねらいがある。工場の製造ラインの名残りもあるのかもしれない。 しかし、こういう仕事の仕方がかえって非効率に感じられて、早朝や深夜に仕事のピークを持っていきたがる人たちもいる。米オンラインニュース「ビジネスインサイダー」は2013年1月14日、「プログラマーが夜、仕事するのはなぜか」と題した記事を掲載している。 スケジュールを細かく刻む「経営者タイプ」と対照的 複数のプログラマーに調査したところ、早朝4時から仕事に取り掛かる人や、逆に朝4時に寝床に入る人などがいたという。いずれも通常の「ビジネスアワー」ではない。 記事では、米国の著名プログラマーであるポール・グレアム氏が2009年に発表した「メーカーズ・スケジュール」を引用。それによると「経営
最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態&設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る
デブサミ2013【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ~10の40乗のパターンをいかにテストするか~ Presentation Transcript DevelopersSummit 自動改札機の 運賃計算プログラムのデバッグ手法 ~1040のパターンをいかにテストするか~14-B-3 幡山 五郎#devsumiB オムロンソーシアルソリューションズ ソリューション事業本部 Developers Summit 2013 Action ! 1.自動改札機について 1. 自動改札機について 2. 間違えない自動改札機 2 1.自動改札機について自動改札機導入前の改札風景 3 1.自動改札機について磁気からICへ求められる技術が変わってきた(高機能化→高信頼化) 2013年 IC乗車券全国共通化(北海道~九州の10種類) 2007年 PASMO導入、Suica+PASMO
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。(原文公開日:2009年3月20日) 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
2012-11-13 Perlで補完のきくインタラクティブシェル perl すなわちRubyでいうpry相当のもの。Perlのインタラクティブシェルは たくさんある のだけれど、自分は Devel::REPL を使っているのでそれを推したい。 Devel::REPL Devel::REPL の何がいいかというと モジュール名やメソッド名の補完がきく もうこれに尽きる。デフォルトでは補完が若干貧弱なので、 ~/.repl/repl.rc を こんな感じ にすればとりあえず快適に使えます。 Examples モジュール名補完メソッド名補完coderefもよしなにdump Devel::REPL を拡張したいとき Devel::REPL::Plugin::* もっと軽いのでいいやって気分のとき Eval::WithLexicals の tinyrepl が軽いのでそっち使ってます。 Cside
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
2012年08月16日08:00 by oklahomer 「私がFacebookで働いていて嫌いな10個のこと」が面白い カテゴリ小ネタ 15日の14時過ぎにFacebookの開発ディレクターが「現役社員がこんなことを書くなんて信じられない」というコメント付きでシェアしていた「Ten Things I Hate About Working at Facebook(私がFacebookで働いていて嫌いな10個のこと)」という記事が面白かったので共有です。 いきなりニュースフィードに流れてきたので、IPO後の初業績報告だとかIPO以来の幹部入れ替わりが話題になってるから社内はピリピリしてんのかなぁ、まだエイプリルフールじゃないしなぁと思いつつ帰宅してジックリ読んだわけですが、読んでみて納得です。考えてみたら、本当にマズい内容だったら開発ディレクターが拡散したりしませんよね。 以下、本文和訳で
隣席のるびりすと氏(@hsbt)と僕とで、この半月ほど、東京・福岡で合計3回にわたって勉強会ツアーをやっていました(その他のこともたくさんやっていたので、それだけではもちろんないのですが)。今日でそれもひと通り終わったので、どのようなことをやっていたのかについて、ここで公開したいと思います。 我々の話はどの回も以下の順番で行われており、いわば三題噺みたいな構成となってます。 リーンスタートアップ インセプションデッキ Scrum それは、我々が議論している模様を撮った以下に掲げた写真に見られるように、開発プロセスというものが階層的な構造を持っているからです。 www.instagram.com ここでは、その最初の話「開発者のためのリーン・スタートアップ」および「リーン・キャンバス入門」のスライドを紹介します。 開発者のためのリーン・スタートアップ 僕は技術者です。また、技術者としてさらな
iOS アプリの構造がどのようになっているのか理解しなくても簡単なアプリを開発することは可能です。実際自分も iOS アプリの開発をはじめたことろはそうでした。しかしアプリの構造を理解していないと複雑なアプリ、例えばタブとナビゲーションを組み合わせたアプリやマルチタッチやジェスチャーを使ったアプリなどを作ろうとしたときにハマることが多いです。 本記事では iOS アプリの構造について説明します。 一番単純なアプリの構造 それでは iOS アプリの中でも一番単純なアプリの構造がどうなっているのか見てみましょう。 iOS で一番単純なアプリは画面を一つ表示するアプリです。画面を一つ表示するアプリはシングルビューアプリケーション(Single View Application)といいます。 ラベルもボタンもなく、ただ真っ白な画面を表示するだけのアプリがどのような構造になっているのかみてみましょう
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
桜の季節が近くなってきましたね。 春といえば出会いと別れの季節です。 我々プログラマも、ともすると4月から就職して新しいプログラミング言語やプロジェクトに出会うのではないでしょうか。 僕は1月に戦場を移動した関係で、1月から初めてRubyに取り組みました。 またObjective-cも書き始めています。 何かの参考になればと思い、今回の経験から僕なりの新しいプログラムへの取り組み方の定石みたいなものを偉そうに書いてみようと思います。 Kiai Driven Development 新しい言語やプロジェクトに出会ったとき、KDD(気合駆動開発)信奉者の僕が気を付けている点が3つ有ります。 それを一から紹介します。 Githubをとにかく巡れ! 新しい言語に取り組むとき、僕はまずGithubのその言語に関するwatchやfolkのランキングを見てます。 ランキングは、Github上部のExpl
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
去年の年末、Facebookで以下の様な画像が流れてきて自分もついついシェアしたんだけど、久々に、というか、自分にとってのここ最近の課題をドンピシャで突かれたような気がして、しばらく頭から離れなかった。 出展: 中村 修治 - 中村 修治さんの写真アルバム | Facebook 「プロ」か「アマチュア」か、というのはこの際どうでも良くて、この図の、上の曲線が、目指すべきところだなって話なだけなので、とりあえずその話をまとめてみることにする。 けど、まぁ、だいたい、こういう話をまとめるのは苦手だし途中で面倒になってしまうので、以下サブセクションだけ先に作ってみたものの、ちゃんと書くかどうかわからない... が、まあ、いい!あと、なんかグダグダ書いてしまいそうだけど、結局、サブセクションのタイトルにしたことをこねくりまわしているだけです。 作ってみるまでわからない 何にも言えることだけど作って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く