（お知らせ） Xamarinを支える技術 at de:code2017 - ものがたり
こんにちは、「ゴールデンウィークがあと1ヶ月続けばいいのに」とついうっかり書いたばかりに、そのGW中にチーム全体がリストラされることになった6年前を思い出しているatsushienoです。ホント、GWがあと1年くらい続けばいいのに。 さて今日は軽くお知らせです。 日本マイクロソフトが5/23、5/24の2日間で開催するde:code2017で、50分のChalk Talkをやります。 Sessions - de:code (decode) 2017 ｜ 日本マイクロソフトの開発者/アーキテクト/IT Pro 向けイベント - Microsoft Events & Seminars 最初はセッションでという話で来たのですが、わたしが直前まで渡米していてちょっと難儀するかもしれないという話をしたら、うまいことチョークトークに転換して、時間も最後の最後のひとコマに調整していただけました。
若手が知らない昔の技術MQ、クラウドではホットだ
「メッセージキューイング（MQ）」というシステム連携方式をご存じだろうか。詳しくは後述するが、クライアント（システムあるいはシステムを構成するサービス）同士が、「キュー」と呼ぶ入れ物を介して、メッセージをやり取りする仕組みだ。 ホスト機の時代から使われてきた実績のある技術で、2000年代前半に注目を集めたサービス指向アーキテクチャー（SOA）では、サービス同士の連携方式として用いられた。企業情報システムの基盤を担当してきたITエンジニアにとって、メッセージキューイングは馴染みのある技術の一つだろう。 ところが2010年ごろからSOAが下火になるとともに、メッセージキューイングは「使っている人しか知らない地味な存在」になっていった。あるアーキテクトは「特に、Web系のシステムから入った若手エンジニアの間で、メッセージキューイングはあまり知られていない」と指摘する。 これは問題だ。Amazon
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
複雑なJavaScriptアプリケーションを考えながら作る話
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
最終掲示板戦争 - ✘╹◡╹✘
こんにちは、r7kamuraです。26年なにも考えずに生きてきて、レールに沿った人生を歩んできました。 さて、数日前からなんとなく気が触れてRuby on Railsで掲示板をつくってみている。上の画像はいまつくりかけのもの。CSS全部手で書いてみてるからまだ見てくれがかなりショボい。最初に手を動かしはじめたきっかけは、2007年頃に「Railsを使って15分で掲示板をつくってみよう！」という記事を見たのを思い出したのがきっかけ。いまのところ10時間ぐらい経過している。15分はちょっと無理そう。2016年にもなって10時間以上かけて掲示板つくってるのは皮肉すぎる事実。もはや何故掲示板をつくっていたのか分からなくなってきつつある。とりあえず濁り切らない内に考えていることを書いておく。最近なんで掲示板つくってんのって聞かれることが増えてきたので、そのときにこの記事のURL出せると多分便利。 掲
【CEDEC2016】アイドルたちをもっともっと可愛く！ Cygamesクリエイターが『デレステ』開発・運営でみせた飽くなき追求 | gamebiz
Cygamesは、「アイドルマスターシンデレラガールズ スターライトステージ 制作事例・アート編 － 総勢60名のアイドルを最大限魅力的に表現し、ライブに集中する手法（モデリングとUI/UXデザイン）」と題するセッションを8月26日開催の「CEDEC2016」で開催した。モデリングパートとUI/UXデザインのパートに分かれており、今回はモデリングパートの模様をレポートする。 モデリングパートでは、Cygamesデザイナー部3DCGアーティストチームマネージャーの谷本裕馬氏（写真）が登壇した。『アイドルマスターシンデレラガールズ スターライトステージ（以下、デレステ）』は、「Mobage」で配信されている『アイドルマスターシンデレラガールズ』から派生したリズムゲームで、App StoreとGoogle Playの売上ランキングで首位を獲得した実績もあるなど、人気タイトルの一つとして定着してい
【CEDEC2016】想定を遥かに上回るユーザーが殺到した『Fate GO』――ディライトワークスが明かした負荷対策とAzureからAWSへの移行 | gamebiz
ディライトワークスのプログラマーの今井守生氏、上野威史氏、ピアレスの田村祐樹社長が「『Fate/Grand Order』における、ディライトワークス流AWS導入＆活用術」と題するセッションを8月24日の「CEDEC 2016」で行った。このセッションでは、大人気ゲームアプリ『Fate/Grand Order』におけるMicrosoft AzureからAWSへの移行、そして活用術を具体的かつ実用的に紹介した。 今回は、今井氏の講演を中心にレポートしていこう。氏は、スパイク・チュンソフトなどを経て、2014年にディライトワークスに入社した。『Fate/Grand Order』においては、サーバー関連の業務を担当しているという。API仕様作成とテーブル構造の決定、実装、コードレビューなどを行っているそうだ。 またディライトワークスの紹介も行った。2014年1月に設立されたばかりのスマートフォンゲ
PHPからScalaに乗り換えたチャットワークさん、その後どうですか？（前編） | HRナビ by リクルート
本当にScala化できるんですか？ 増井：今日は、チャットワークをPHPからScalaに切り替えるお話を伺うためにやって来ました。 山本：はい。 増井：僕がこの話を知ったのは、ちょうど2年ぐらい前に読んだブログのエントリだったんです。いきなり失礼なんですが、僕はこの話を知って、ぶっちゃけアホじゃないかと思ったんですよ。 山本：あはは（笑） 増井：基本的に開発言語やフレームワーク、方法論を同時に変えるって結構大きな変更ですよね？ 山本：そう思います。 増井：それなのに、この決断を発表された当時、御社にはScalaエンジニアがいなかったそうじゃないですか。「本当に大丈夫なのかな？」と思って、気になってたんです。昨年春には「Scala採用を決めて一年たった、CTOの雑感」というエントリをポストされていましたが、さらに1年経った今はどんな状況なんですか？ 山本：ひと言で申し上げると「絶賛移行中」と
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS （Microsoft Consulting Services） の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが；、二回分のエントリを通して読めば、牛尾さんが言いたい
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
Javaと偽Javaの話。 - なるようになるかも
qiita.com これの話。ブコメに書こうとしたら4000字は入らなかった。 Microsoft Java VM かつての WIndows には MS 製の Java VM が搭載されていました。 古代の Java は「Write once, run anywhere」を掲げていた通り、クライアントサイドで Java アプレットとして利用されるのが主流でした（サーバーサイドで動くようになって、真価を発揮した感じがあります）。 しかし Java VM の仕様は、パフォーマンスについての記述は曖昧になっており、OS ごとの実装の違いによって、実行速度に顕著な差がありました。 Windows の Sun 純正の Java VM は性能が悪かったため、MS は独自の Java VM を開発し、Internet Explorer にバンドルしました。調子に乗った MS は Windows GUI
AbemaTVのランタイムパフォーマンスのAudit - 1000ch.net
2016.05.17AbemaTVのランタイムパフォーマンスのAudit最近業務で、巷で話題のAbemaTVのパフォーマンス改善をしている。個別具体性が高いが調査改善の雰囲気を感じ取ってもらえればそれで良いかと思い、記事にした。 AbemaTVのフロントエンドの構成話の前提となるAbemaTVのフロントエンドの構成は次の通りで、まさに流行りのといった感じ。 facebook/reactfacebook/immutable-jsReactive-Extensions/RxJSreactjs/react-routercss-modules/css-modulesビルド周りはbabelとwebpack、あとはlintツールがちょこちょこ入ったりしている。この改善の話と関係してくるのは、ReactとImmutableJSとRxJSだけ。 番組再生画面のコメント開閉が重い今回ケーススタディとして挙げ
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
MacOSとWindowsのネイティブ仮想化を用いたDocker純正ツール「Docker for Mac/Windows」登場、VirtualBoxは不要に
MacOSとWindowsのネイティブ仮想化を用いたDocker純正ツール「Docker for Mac/Windows」登場、VirtualBoxは不要に これまでWindowsやMacOSの上でDockerを試すには、それぞれのOS上でLinuxを動かすために仮想マシンのVirtualBoxをインストールする必要がありました。しかしOS上で仮想マシンを動かす処理は、重く不安定になりがちでした。 Docker社はこの方法に代わる新しいツール「Docker for Mac and Windows」のベータ版を発表しました。 Docker for Mac and Windowsは、それぞれのOSのネイティブアプリケーションの形式で提供され、VirtualBoxの代わりにそれぞれのOSに組み込まれている仮想化機能、WindowsではHyper-V、MacOSではxhyveを用いることで、より高
npmからkikとその他諸々が消されたまとめ
npmとは、node.jsにおけるパッケージシステムのことだ。npmを使えば、他人の書いたnode.jsベースのプログラムとライブラリの入手と利用がとても簡単になる。 そのnpm界隈が混乱している。発端は以下のURLだ。 I’ve Just Liberated My Modules — Medium Azer Koçuluはkikという名前のnpmパッケージを公開していた。このkikというソフトウェアの中身についてはここでは関係がない。 さて、それとは別に、kik.comというスマフォ用のチャットアプリを出しているKik Interactive社がいて、kikという名前のパッケージをnpmで出したいので、名前を明け渡すように要求した。 Azerはこの要求を拒否した。すると、Kik Interactive社はnpmの管理者に片っ端からメールを投げまくり、そのうちの一人が反応して、Azerの意
npm パッケージの unpublish に関するゴタゴタの大まかなまとめ - ヤルキデナイズド
（最終更新：3月24日16:50ごろ） 事件の流れ kik の作者が同名の会社 KIK の弁護士特許出願代理人からパッケージ名を変更するよう要請される 作者が拒否したところ弁護士代理人は npm の運営にコンタクトする 運営が作者の許可なくパッケージを unpublish するパッケージの所有権を移し替える 作者がこれに反発し自身が所有する270あまりのパッケージをすべて unpublish する I’ve Just Liberated My Modules — Medium unpublish されたパッケージは npmjs.com からダウンロードできなくなる unpublish されたうちのひとつである left-pad に間接的に依存したパッケージが多数あったため世界中でビルドがぶっ壊れる npmjs.org tells me that left-pad is not availa
「PCをWin7のままにしておきたいのに強制的にWin10にするMSが嫌だ！Linuxに行く！」という方へLinuxユーザーとして言っておきたいこと
「PCをWin7のままにしておきたいのに強制的にWin10にするMSが嫌だ！Macに行く！」という方へMacユーザーとして言っておきたいこと という記事を見かけたので、Linuxデスクトップユーザーからも一言だけ言っておく。 結論から。 「悪いことは言わないからやめておけ！」 以前、いますぐWindowsを捨ててデスクトップでGNU/Linuxを使う10+の理由というエントリを書いたことがあるので、使っちゃいけないみたいなことを書くと、「おいおい、いまさら何言ってんだよ」と思われる方も居るかも知れない。だが、以前のエントリの主旨は「GNUのWindows移植版であるCygwinを使うぐらいだったらGNU/Linuxはいかが？」という提案をするためのものであり、いわばCygwinを使うようなIT技術者向けのメッセージである。Cygwinが必要だということは、UNIXライクなツール群を必要とす
Pelletkachels.nl
Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
吉祥寺.pm でエンジニア立ち居振る舞いについて話してきた - パルカワ2
