クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
学生だってちゃんと開発したい！大学の授業でスクラムを導入しようと思った話 - Man page of CHIKU_WAIT(2)
前提 僕が居る公立はこだて未来大学では3年生の必修授業で「プロジェクト学習」と呼ばれる学科・コースの枠を超えた通年の開発演習があります。この授業ではサービスの開発や心理学研究、楕円曲線暗号のアルゴリズムの高速化やアルゴリズムの改良といった様々なテーマで最大15人程度のチームを組んで1年間取り組みます。実社会に根ざした問題群を解決していく方法を探求する取り組みらしいです。また、教員はあくまでもアドバイザーで、どんなことをするのか、何で開発するのか、どう開発していくのか、スケジュールはどうするのかすべて学生が主体となって決めていきます。そのため、チームによってですが、授業の時間以外も時間を費やすことが多く、3年生はプロジェクト学習に全力を注ぐと言っても過言ではないと思います。詳細はこちらを参照。www.fun.ac.jp 僕が所属しているプロジェクトは「ビーコンIoTで函館のまちをハックする
2018-03-30 技術導入とその運用設計を考える 〜 過去と未来と — OpsLab
2018-03-30 技術導入とその運用設計を考える 〜 過去と未来と¶ 2018年3月30日開催の持続可能なモノづくり・人づくり支援協会 (ESD21) 特別フォーラム「持続可能な技術を考える」における発表資料です。 イベントページ: https://www.esd21.jp/news/2018/03/sit-forum.html 中京大学工学部教授 鈴木常彦先生(tssさん)から、なかなか難しいテーマを宿題としていただいたのですが、現時点(2018年3月)で波田野が考えていることを、総ざらいしてまとめてみました。 名古屋近郊の自動車メーカや建設系企業、IT企業の方々にご参加いただき、いろいろご意見を伺うことができました。 ありがとうございます。 個人的には、伊勢神宮が永らく続けている「式年遷宮」や名古屋のメーカが誇る「形式手法」「関数型言語」活用を軸とした名古屋らしい尖ったモノづくり文
すべてのプログラマが機械学習を受け入れる準備をする時代になった - mizchi's blog
という予感がしたので書く。正確に言うと機械学習の成果としての訓練モデルを。 まず事前に前置きしておくと、僕は機械学習をほとんど抑えていない。トレンドだけ追ってる。 大学生の時にニューラルネットワークを実装してみてフ～ンって言ってた程度に知識しかなくて、ディープラーニングが流行る前だから、「バックプロパゲーションってややこしかったけど、今は自動でモデルの最適化いい感じにやってくれるんでしょ？」ぐらいの雑な理解しかない。(この時点で怪しい) で、今はフロントエンドやってて、ここは機械学習は縁遠いように思えるかもしれないだろうけど、最近のGoogleはなんとブラウザで tensorflow を動かすのに情熱を注いでいる。 で、こんなのが Hacker News で流れてきた。 medium.com とりあえず試した。デモをそのままデプロイした。 PoseNet - Camera Feed Dem
公開して３週間で収益１０万円を得た個人開発サイトについての考察 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
公開してまだ３週間ほどだし、収益としても１０万円でしかないし、大きな事は言えないがここで個人開発サイトとその収益性について考えたことを記しておく。 世の中には＊＊億ドルのバリエーションを獲得したスゲー起業家の話か、個人開発サイトを立ち上げたものの収益なんてゼロに近くサーバー代とトントンの話かの両極端しか無いように感じる。 パッと立ち上げてだいたい１ヶ月でiPhoneXが買えるぐらいのサイト規模というのは、どんなレベルのエンジニアでも手が届く範囲内にあるのが実感だ。「人生賭けて起業！」とかそんな熱い話ではない。普段の仕事が終わったら、ちょこちょこコードかいて個人的にアプリを公開して収益を得る、ぐらいの話でしかない。「１億総クリエイター時代」なんて言われる昨今では、どんなエンジニアもこんな感じのやり方が世の流れに合っている気がする。 サイト内容 今回、開設したのはざっくり言うとこんなサイトだっ
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
個人開発のやっていき方
2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。
エンタープライズアジャイル勉強会の資料 - @m_seki の
エンタープライズアジャイル勉強会という勉強会に呼んでいただけたので資料公開しますね。広島の旅費が苦しいのでこういうのうれしい！ Gumroadからの課金勢のみなさんへ 恒例！スライドに名前を入れる券 2017-2018 反復開発を中心に お話したこと 反復開発は全工程やって1ターンだよっていうみんなが知ってる（けど、ある方面のScrumではやられていないことが多いらしい）ことを45分間ずっと説明しました。 その結果チームの境界（サブシステムとか工程別チームとか）がどうでもよくなると思う（実感してる）んだけど、Scurm Incの説明だと階層がたくさんある例を示していたし、永田さんはQA部門にこだわりがあるのがおもしろいなー。自分も含めて、みんな自分の状況が好きなんだな。いいことだ。 再演バイト待ってます。 （再演したいんじゃなくて、RubyKaigiの旅費かせぎたいので！） speaker
スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
Panic Blog » ソースコードの盗難について
先週、動画変換ファイルアプリ HandBrake のMac版によってマルウェアに感染との報道がありました。（日本語記事参考: 動画変換ソフト「HandBrake」Mac版にマルウェア感染の危険性 | CNET Japan）2つの配信サーバのうちの片方で、感染したHandBrakeアプリが3日間公開された状態になっており、ダウンロードして起動するとそのコンピュータは攻撃者による遠隔操作が可能な状態になる、というものです。 運が悪く、さらにコンピュータ運にも恵まれず、公開されていた3日の間に感染したHandBrakeをダウンロード、起動したためにプログラマのMacが感染してしまいました。 その結果、どこかの、誰かに、私たちのアプリのソースコードが盗まれました。 続けて、以下の大切な3つについてお知らせします: ・今回の攻撃者がユーザ情報にアクセスした兆候はまったくありませんでした。 ・さらに、
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
「まだ６０回しか稲作したことがない」という含蓄ある言葉 - masayang's diary
昨日は旧友たちと錦糸町のホルモン焼き屋で飲む。 一人は自営業の傍ら、稲作をしているおっさん。 今年で稲作6年めだとか。 以下、印象に残ったお話。 最初は手探り状態。近所の農家に指導をしてもらった。 「おいしい」米を作れる技術を持っているのは70歳の世代まで。 その後継者になるべき世代(たぶん、うちらの世代)は農政と農協のおかげでボロボロ。 その70歳のおじいちゃんが「自分はまだ稲作を６０回しかしたことがない。だからよくわからない。」と言ったそうな。 含蓄ある言葉だな、と思った... 確かに米は年一回しかとれない。 しかも気象条件は毎年必ず変わる。 そういう中で試行錯誤できる回数は、一生のうち数十回。 こんな技術はマニュアル化など到底できない。 習い(あるいは盗み)、伝えていくしかない。 実践(プラクティス)あるのみ。 システム開発も似たような所はあるよね。 一生のうちに経験できるプロジェク
プログラマが「出来ません」と言う日 - megamouthの葬列
長い間、フリーランスなどという「便利屋」をこなしていると、馴染みの顧客から、トラブったプロジェクトに急遽参画してほしいという、ヘルプ案件が入ってきたりする。 嫌かと言われるとそうでもなく、むしろ、恩を着せて（足元を見るとも言う）高単価を取るチャンスだし、案件が燃え上がっているのは他人のせいであり、途中から入る私は気楽なものなので、積極的に首をつっこむことにしている。 こう言うと颯爽と現れるスーパーマンのようでかっこいいのだが、そこはクソ雑魚フリーランスの私。トラブルの内容というのは、「安いWordpress業者に頼んだ案件で、途中で、（カスタマイズ要件）がやっぱり出来ないと言われた」とか「アプリが毎回メモリリークで5分で落ちるのだが、全く治る気配がない」とかそういう情けない話ばかりである。 共通して言えるのは、炎上させた業者が「（問題を解決することが）出来ません」とはっきり言ってしまってい
チームで仕事をすることについて
こんにちは、 Kaizen Platform, Inc. に入職して 1 年 3 ヶ月の Hitoshi Nakashima と申します。普段は福岡市で生活しており、遠隔にて就労しております。小社ではウェブアプリケーションエンジニアとして勤務しており、主に Ruby on Rails で構築されたウェブアプリケーションの開発・保守を行っています。最近では Kaizen Chat と呼ばれる Kaizen Platform ユーザー向けの Chat ソフトの開発に関与しました（小社製品をご利用の皆様でまだ Kaizen Chat をお試しいただいたことがないという方がおられましたら是非一度お試しください）。 個人では年に一度（主に年末）、失敗談や暗い話をブログに投稿してソーシャルネットワークの耳目を集めることを主な活動内容としております。 今日は最近のチームで仕事をすることについて話したいと
伊藤直也さんの一人CTO Nightに一人で行ってきた - comix
巷で話題？のnaoya さんの一人CTO Nightに行ってきましたので、超雑ですがメモを公開しておきます。 イベント詳細： https://doda.jp/event/seminar/20160830.html オレオレメモなので多少ニュアンス違うところあるかもです。特に二部のパネルディスカッションの部分はかなり文脈を端折っているので雰囲気知るくらいに読んでもらえれば。 もし大きく間違っていることあったらご指摘くださいm(__)m ちなみにアニメの話はあんまりなかったよ。 では、早速。 第一部【プレゼンテーション】最速で最高のアウトプットを生み出すチーム作りとは？ 【プレゼンテーション内容】 CTO・技術顧問を複数社経験した伊藤直也氏が、過去の実際の事例をもとに、最高のアウトプットを生み出すチーム作りを解説します。 前提として、、、 50〜300人くらいの規模の組織が対象 CTOのマネジ
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う
System of Record と System of Engagement
Google の新しい専門職 : CRE が必要な理由
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）
