だいぶ間が空いてしまったんですが、デブサミ 2016 で非同期処理について話してきました。 event.shoeisha.jp トピックとしてものすごく突出してたので成立するか不安だったのですが、なんとなく結論めいたものはでました。 詳しくは takezoe さんのブログを見て頂けると良いかと思います。 takezoe.hatenablog.com 結論みたいなもの まぁやっぱり同期処理と非同期処理は『意識して使い分けなくても言語なりフレームワークなりで吸収するようになっていくんじゃないか』というのが1つの結論のような形になった。ES.Nextの async/await はその1つの形だと思う。"意識しないで"というのは難しいが、ほとんど同期処理と変わらない形で書けるようになる。 Node.js は coreの中でも Promise を採用するように只今構想中だし、ユーザーランドの場合はP
(訳注:2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注:著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例: 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
2016-02-09 This post talks about Ruby but it’s true of every language community: Python, JavaScript, Java, etc. The scourge of dependencies spares no one. This is a dependency visualization of every Rails app I’ve ever used. Does any of this sound familiar: Gemfile with 100s of entries. Test gems loading in production. Each Rails process takes 100s of megabytes of RAM. The Rubygems system is comme
10 golden rules for becoming a better programmer | codeshare.co.uk .Net Web Developer Blog by Paul Seal この手の記事には食傷気味だが、学ぶべき教訓には学んだほうがいいわけで、果たしてここではどんな10個のルールが示されているのか。 同じことを繰り返さない(コードのリファクタリングの勧め) 変数には、それがどんな型かではなく、それが何のためにあるか分かる名前をつける メソッドには、それが何をするか明確に分かる名前をつける マジックナンバーや文字列リテラルは使わない 可能であれば、メソッドはそのアプリの他の部分に依存性を持つことなくテストできるよう書く 助けを求めるのを恐れない(やってることを他人に説明するプロセスが問題解決につながることもある) ボーイスカウト・ルールに従う(バグのあるコー
『 APIデザインケーススタディ 』という本を頂戴したので読んでみた。 ライブラリ作者に向けて この本はRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんて本が書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な
はじめに こんにちは、エンジニアのあさりです。今回は、AdminJSというNode.jsのフレームワークを用いて簡単に管理画面を実装する方法を紹介します。 AdminJSとは? AdminJS は、Node.js アプリ […]
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
技術トレンドを追わないという勇気 昨日、「第19回 HTML5+JS 勉強会 【オレオレフロントエンド開発環境 ~際限なき修正を攻略せよ!~/甦れFlasher「swf2js」でswfをリアルタイムでcanvasに出力】」というイベントに参加してきました。 そこで講師の沖さん(@448jp)が、�「技術は目的を達成する手段なので、あまり新しい技術に振り回されてはいけない。」的なことをおしゃっていて、それはそうだなと思いながら私が最近感じている事をすこし書き留めておこうと思います。 技術トレンド圧力 フロントエンド界隈ではJavaScript/node.jsの盛況もあって毎日のように新しいライブラリ/フレームワークやツールがリリースされています。そして、それらの技術に対してアーリーアダプター的なフロントエンダーが試してはブログやQiitaでレビュー内容を記事にしたり、TwitterやFace
計算機プログラムの構造と解釈、通称SICPを一から翻訳し直しました。 ファイル: SICP非公式日本語版 翻訳改訂版 リポジトリ: https://github.com/hiroshi-manabe/sicp-pdf また、今回の翻訳をするにあたって考えたことを別記事にまとめました。 腐った翻訳に対する態度について SICPはMITの有名なプログラミングの教科書です。詳しくはminghai氏の記事をご参照ください。 この翻訳改訂版は、minghai氏の非公式日本語版(以降、minghai氏版)のあまりにも惨憺たる翻訳を見かねて、原著から翻訳をし直したものです。この翻訳を進めるにあたっては、minghai氏版の訳を置き換えていくというやり方で進めていきました。しかし、差分を取ればわかっていただけると思いますが、minghai氏版のテキストは痕跡をとどめていないはずです。この方式を採ったのは、
今年、クックパッドでは夏のインターンと題して20名弱のインターンを受け入れました。 このインターンは前半と後半に大きく分かれており、 後半が社員に混じって業務をするいわゆる普通のインターンで、 前半は7日間にわたってプログラミング関連の講義を受けるという仕組みです。 わたし(青木)はその前半の過程において、「プログラミングパラダイム」という 1 日の講義を担当し、 JavaScriptの処理系を書くという、ツッコミどころの多い課題を実施しました。 本稿では、その講義を開発する際に考慮したこと、特に難易度調整についてお話しします。 また講義のために開発したJavaScript処理系「JetSpider」についても軽くふれます。 ▼講義資料 Cookpad Summer Intern 2015 - Programming Paradigm from Minero Aoki JetSpiderコ
ユーザーは想定以上に広がっている――。3年前ぶりに「超高速開発」について取材を重ねた結果、記者は素直にそう感じた。 プログラムを100%自動生成するツールを用いて開発スピードを飛躍的に高める開発手法を「超高速開発」と名付け、特集「『超高速開発』が日本を救う」を日経コンピュータに掲載したのが2012年3月。同月には関連記事として記者の眼に「あなたの知らない超高速開発」を掲載した。 ことさらバズワードを生み出したいという気持ちはなかったが、ネット上の反響を見ると懐疑的・批判的な声も少なからずみられた。3年前の話で恐縮だが、業務ロジックを記述・設定すればプログラムを100%自動生成するとうたうツール群について「本当にできるのか」という投げかけもあれば、「また自動生成か。同じことの繰り返しだ」という、おそらくは過去にCASEツールで手痛い目に遭ったり「Σ(シグマ)プロジェクト」の“失敗”をご存知の
security, standardization は、登壇者の撮影を一切禁止します。 トーク内容は事前には決めないため、トークの概要といったものはありません。 昼食は、休憩時間に校内・教室で食べることもできます。学校の 1 階にセブンイレブン、近くにほっともっとがあります。 Wifi あり、一部座席には電源があります。 Speaker server_perf @mirakui: @xcir: インフラエンジニア / Varnish Cache大好き [GitHub] [xcir.net] @cubicdaiya: Software Engineer in Infrastructure Engineering [Profile] accessibility @bakera: HTML/情報セキュリティ/アクセシビリティ関連の話が好きな人。最近関わった本:[コーディング] [デザイニング]
買物情報事業部の八木です。クックパッド特売情報のAndroid部分を担当しています。普段はクックパッドのAndroid版(以後、本体アプリとします)の開発プロセスの中で特売情報の機能を開発しています。 本エントリでは細かな技術的負債を解消する為に本体アプリの開発チームが行っている朝Lint活動を紹介します。 2年近く経つ本体アプリのコードベース 私が買物情報事業部に所属する前は本体アプリを1から書き直すチームで働いていました。書き直し始めたのは2013年10月からなのでそろそろ2年が経とうとしています。2年前に設計された本体アプリは現在ではおよそ17万行を越え、日々どんどん変更が加えられています。 それらの変更の中には残念ながら悪いコードが含まれている場合があります。テストしづらいコードやテストがないコード、レビューに対する場当たりな対応や緊急のbug fixのために追加された汚いコード、
これを書くことによってYAPCが終わる そもそも自分も発表申し込もうかなとは思ってたけど、@teppeis @koba04 @yosuke_furukawa @Jxck (敬称略)が喋る時点でJS方面の界隈としては役満感があったしみんなフロントエンドの話そこまでして聞きたくないやろ、という感じで申し込まなかった。彼らの話はどれも評判良かったのでめでたい。 1日目 朝起きれなかったのでラリー・ウォールみてない。 Matzのセッションとてもよくて「今日はRubyの話をしません」「ネタが尽きたのでRubyの話をします」「Rubyの言語デザインの最大の失敗はPerlの影響を受けたこと」というコンボがよかった。 質問タイム、「TypeScriptとかで動的型付けの言語に静的型のタイプヒンティングいれるの流行ってるけど、Ruby3.0のソフトタイピングは開発者支援とコンパイラ支援どっちを目指してますか
The Art of Computer Programming Volume 1 Fundamental Algorithms Third Edition 日本語版 Donald E. Knuth(著), 有澤誠, 和田英一(監訳), 青木孝, 筧一彦, 鈴木健一, 長尾高弘(訳) アスキードワンゴ 4,224円 (3,840円+税) アルゴリズムのバイブル――Knuth先生の名著『The Art of Computer Programming』シリーズの第1巻! Volume 1「基本アルゴリズム」では、コンピュータプログラムの基礎概念と情報構造を学習します。 関連サイト本書の関連ページが用意されています。 The Art of Computer Programming Volume 1... - アスキードワンゴ内容紹介◆アルゴリズムのバイブル――Knuth先生の名著『The Art
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く