私的な 2015 年技術的な振り返り - Qiita
Help us understand the problem. What is going on with this article? 自分のことだけではなく会社的な話も一部含む Pocket のログを見てたら今年は結構狭い技術の中で生きていたことがわかった。 Erlang/OTP ほとんどの時間を Erlang を書くことで過ごしていた気がする。 WebRTC を主にやっていたことから様々なプロトコルを実装したし、たくさんのバグを踏んだ。 Erlang が 1 プロセスでできる処理性能が秒間 5 万リクエスト程度とそんなに高くない事から、ほかの言語への移動も色々検討していた。 CTO に Rust を試してもらったり、知り合いのミドル系の人に相談したりしても、結局は Erlang を頑張る方が良いと思う。という回答を多く頂いた年だった。 結果的に Erlang ばかり書いていた気がする。
Obj-C → Swift コンバータをオープンソースで公開しました！
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog どうも、ヤフーの佐野（ @taketo1024 ）です。先日引っ越しをしまして、張り切って自分でタンスを運んだりして今とても筋肉痛です。 皆さんは Objective-C から Swift への移行は進んでいますか？弊社ではまだ Obj-C で書かれているプロジェクトは多くあります。世に出ている iOS アプリも多くはまだ Obj-C で作られているんじゃないかと思います。 Swift もオープンソース化され、この先その進化のスピードはさらに増してくるはずです。そこでチーム内で開発を進めていた Obj-C → Swift コンバータ を大幅に改良しオープンソースで公開することにしました！この記事ではその導入と活用の方法を説明します
Scala使用歴5年のプログラマが、この言語とその環境に関する神話を解き明かす | POSTD
(注：2016/1/21、頂いたフィードバックをもとに記事を修正いたしました。) 『 Programming in Scala (Scalaでプログラミング) 』の初版を読み始めた（でも読み終えていない）5年前からJavaの代わりにScalaを使うようになりました。最初はテストの時に使用していましたが、すぐにちょっとしたユーティリティクラスでも使用するようになり、気付いたらプロジェクト全てで使用するようになっていました。 Scalaに対する不満は多く存在しますが、この記事は違います。これは非難するものではなく、むしろ称賛するものです。 Scalaに興味ある開発者や聞いたことがあっても詳しく見たことがない人、「スムーズなプログラミングの妨げになる」と思い使用を先送りしていた人のために書きました。もちろんScalaファンに読んでもらうのも、他の人にも紹介してもらうのも大歓迎です。 この記事は3
朝の自由改善開発、進捗いいです - Konifar's WIP
クックパッド社の 朝Lint活動の記事を見て、最高じゃん…！と思い自分も真似して運用してみることにしました。 techlife.cookpad.com とりあえず自分だけで勝手にやることにしたので 「Lint警告解消に限らずやりたいこと好き勝手やってやるぞ！」って感じで2週間くらいやってみました。わりと進捗よくて成果出てきた気がするので、どう考えて何をやったかを残しておこうと思います。 なぜやろうと思ったのか 普段の開発タスクに追われて細かいところに手がつかず歯がゆい思いをしていたからです。 今作っているTaptripはグロースフェーズにあり、新規ユーザーの流入やDAU・MAUの向上といった数字から逆算した施策を高速にこなすべく開発を進めています。 この方針自体には納得しているんですけど、直近で数字が出るかよくわからない細かい改善というのはやはり優先度が低くなってしまうんですよね。そしてそ
夏の技術職インターンシップ講義資料公開 - クックパッド開発者ブログ
こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 このまえ夏の技術職インターンシップの前半の開発講義・課題部分が終わったのでさっそく公開しちゃいます！ ちなみにこのインターンの対象者はプログラミングはわかるし自分で（授業とかではなく）コード書いている人なので超初心者向けでは無く、少なくともひとつ以上の言語でプログラミングが出来る人向けです。 一日目 TDD + git 編（@yoshiori） 講義初日なのでまずは簡単に肩慣らし & 開発の基礎の部分として TDD と git で始めました。 git については軽く説明し TDD は基本のテストファーストで進めて行きました。 ちゃんと何かをするたびにテストを実行し、メッセージを見れば次にすることが分かるというのを体験してもらい、GREEN が良くて RED が悪いのではなく、GREEN を想定しているのに
作り直し - hitode909の日記
ソフトウェアを作ってて、作り直したり、書き直したりするべきかどうかという話をすることがある。 大きな規模だと、ソフトウェアを作り直す、というところから、小さな規模だと、込み入った機能を書き直す、くらいまであるけど、作り直すとうまくいくのは、次の二つのうちどちらかではないか。 最初に作ったときより世の中の技術が発展したとき 昔のコンピュータでは収まらなかったとか、昔は良いライブラリがなかったけど、今はある、というとき。 単に今ありふれた技術で作り直すと、よいものができそう。 最初に作ったときよりはコンピュータのスペックが上がったので、そのつもりで、並列度倍に上げても止まらないし、より速く動かせる、とか。 昔はバッチで計算しないといけなかったけど、今ならリアルタイムに返せる、とか。 昔は依存管理のよいライブラリがなかったけど、今ならこれ入れたら簡単、とか。 最初に作ったときより人間の技術が発展
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブ
共通化でモチベーションと効率が低下した話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二
Sign in - Google Accounts
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
Android再入門 〜Eclipseのことは忘れろ〜 #nds40 - Qiita
※本記事は、長岡IT開発者勉強会#40 初心者Dayで話す内容のドラフトとして書かれたものです。 ※本記事は、2015年2月時点での技術に関する時事ネタを多分に含んでいます。ご留意ください。 2/26 この記事のメイキング記事を書きました。 はじめに Androidが世に出た2008年秋からもうすぐ7年が経とうとしています。日本で初めてのAndroidスマートフォンであるHT-03Aがドコモから発売された2009年夏からは、もうすぐ6年です。「ツートップ戦略」が記憶に新しいXperiaやGalaxy Sシリーズが出始めたのは2010年ですから、そこからも5年は経とうとしています。 十年一昔、という言葉がありますが、Web方面に関わっていると三年一昔という言葉が脳裏をよぎることすらあります。7年足らずの歴史しか持たないAndroidにとっても、3年という時間は半生と呼ぶに差し支えないものでし
「10倍プログラマ」の神話、Ruby on Railsの生みの親が語った高い生産性のカギとは!? | HRナビ by リクルート
ずいぶん前のことだが、Webアプリケーション開発フレームワーク「Ruby on Rails」が00年代後半にブームを巻き起こしたとき、強い主張を持つソフトウェアとしてRailsは多くの議論を呼び起こした。その中でも最大のものはプログラマの生産性に関するもの。当時、すでにいくつも存在していたJavaベースのWebアプリケーション開発フレームワークに比べて、Ruby on Railsは10倍の生産性を達成できるという主張だ。 Rubyの生産性はJavaの10倍――。この主張が多くのエンジニアの琴線、もしくは逆鱗に触れた。「さすがに10倍は大げさだ」、「いや、現実に設定ファイルやコードを書く行数が劇的に減るのだから、そのぐらい当然だ」と意見が分かれたのだ。 2005年のリリースから約10年。Railsの生みの親で、今もプロジェクトをリードするデイビッド・ハイネマイヤー・ハンソン氏は当時を振り返り
プログラマを悩ませること Top 10 | POSTD
10. 「何か」は分かるが「なぜ」が分からないコメント プログラミング入門コースでは、早い段階かつ頻繁にコメントを記述することを生徒に教えます。プログラムを書き始めた初期段階（ごく単純なコードであっても、時に理解し難いことがあります）では、これは実際に役立つことなのですが、習慣にとらわれてしまうプログラマが多くいます。 上記のコードが何をするのか分かりますか？ 私は分かりません。 問題は、多くのコメントがそのコードが 何をする のかを説明していますが、 なぜ そのコードが書かれているかが説明されていません。では、異なるコメントが書かれた同じコードを見てみましょう。 こちらの方が分かりやすいですね。何が起きているのかを完全に理解できるとは言えませんが、最低でもなぜこのコードが必要なのかが文脈から判断することができます。 コメントは、構文を理解してもらうためにではなく、読み手がコードを理解しや
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
Cloud9 - Your development environment, in the cloud
AWS Cloud9 is no longer available to new customers. Existing customers of AWS Cloud9 can continue to use the service as normal. Learn more. AWS Cloud9 is a cloud-based integrated development environment (IDE) that lets you write, run, and debug your code with just a browser. It includes a code editor, debugger, and terminal. AWS Cloud9 comes prepackaged with essential tools for popular programming
エターナらないゲーム開発
ゲームの仕様書を初めて作成する人のための足掛かりのスライド ▼以下のスライドを一つにまとめました ・ゲームの仕様書を書こう１ 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ・ゲームの仕様書を書こう２ 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ・ゲームの仕様書を書こう３ 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ・ゲームの仕様書を書こう４ 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-17333
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ～「テスト」という工程が必要な理由 | きのこる庭
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CEDEC2014 「ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～」
プログラマが欲しい仕様書とは
