paizaラーニングは、オンラインでプログラミングしながらスキルアップできる、プログラミング入門学習コンテンツです。
paizaラーニングは、オンラインでプログラミングしながらスキルアップできる、プログラミング入門学習コンテンツです。
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ15年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか?ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
複雑かつリッチな体験を提供するスマートフォンアプリを開発するためのチームワーク、その中でのエンジニアの役割について
みなさんこんにちは。 技術組織戦略G & 技術内閣の板敷です。 普段はAmebaのシステム障害の火消し → 障害対策ならびにエンジニアの育成評価等をしています。 今回は、先日終了したサイバーエージェント新卒エンジニア技術研修について紹介したいと思います。 研修概要従来の研修内容を一新、内製での技術研修に挑戦 これまでの新卒技術研修は委託先講師の話を新卒全員が聞くという、いわゆる「座学中心」の研修でしたが、ここ数年の技術的進歩、組織内でのエンジニアに対する期待の変化を反映するため、内製での研修へとゼロから再設計しました。 研修のコンセプトと概要 ベースとなる研修のコンセプトは以下2点からなります。 全体のアーキテクチャを俯瞰して設計、技術選定をする自分の頭で考え、動くこれらのコンセプトを実現するために今回の研修では、2つの某有名サービスを 自分たちで設計、実装するという形をとりました。 研修
チーフエンジニアの id:Songmu です。 4月に 新人エンジニア研修を行なった のですが、その際に、「インフラを意識したアプリケーションの書き方」という講義を担当しました。そこでおこなった講義の内容について整理しながら書き起こしていきたいと思います。 インフラを意識すると何が良いか 業務でWebアプリケーションを扱うと、個人ではなかなか扱えないトラフィックであったりデータ量を扱うことになります。小規模サービスでは考えなくてよかった多くのことを考慮する必要がでてきます。なかなか体験できないことでもあるので、楽しく、やりがいもあります。 また、そういった経験を通して、インフラを意識しコードをかけるスキルを身につけることは、Webエンジニアとしては大きな強みとなります。ISUCONで優勝できるかもしれません*1。 インフラを意識すると何が良いか 〜 中規模ベンチャーの場合 そもそも、はてな
Googleに買収されたサービスAptureでCEOを務めていたトリスタン・ハリス氏が、ユーザーのサービス依存度を高めるためにテクノロジー企業がどのような手法を取り入れているのかを解説しています。マジックの経験があるハリス氏は、その手法を人間の心理を上手く利用している点でマジックに通じるところがあると評価しています。 How Technology Hijacks People’s Minds — from a Magician and Google’s Design Ethicist — Medium https://medium.com/@tristanharris/how-technology-hijacks-peoples-minds-from-a-magician-and-google-s-design-ethicist-56d62ef5edf3#.aec83wojz IT企業が出
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』 こんにちは、谷口です。 ディレクターやプロジェクトマネージャーといった非エンジニア職の方々は、エンジニアとコミュニケーションをとることに難しさを感じたり、考え方にギャップを感じたりしたことがある方もいらっしゃるかと思います。 「エンジニアとわかりあえない…」「エンジニアが何を考えてるのかわからない…」という方のために、エンジニアとのトラブルのもととなるやりとりや、気を付けるとよいことを考えていきますので、非エンジニアの方々の参考になればと思います。 ■「どれくらいでできる?」はその場で決められるものではない 非エンジニアとエンジニアのもめごとの原因で多いのが、スケジュールに関することです。 非エンジニア「この機能どれくらいでできる?」 エンジニア「一日でできます」 非エンジニア「じゃあ明日リリース
弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について本人同意済み。弊社特有の部分は一部省いています。) ああ、なんという長い旅だったろう。この会社で5年間もセキュリティを担当していたよ(諸々の失敗は許してくれ) 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、
アプリマーケティング研究所 > アプリ開発 > 貯金1,000万円つかって、6年で20アプリつくったが、年収は15万円。どん底アプリ開発者、コンテストで賞金250万円を獲得し、人生初勝利をおさめる。 貯金1,000万円つかって、6年で20アプリつくったが、年収は15万円。どん底アプリ開発者、コンテストで賞金250万円を獲得し、人生初勝利をおさめる。 名古屋で戦いつづけている、個人アプリ開発者さんを取材しました。 ※個人アプリ開発者の、伊与田貴司(Takashi Iyoda)さん。 年収15万円、6年間の貧乏アプリ開発 簡単に自己紹介をお願いします。 伊与田です。名古屋で6年ほど、アプリをつくっている個人開発者です。アプリで独立する前は、いろんな会社で働いていました。 月400時間はたらいて、年収300万円という、システム開発会社で働いたこともありますし、コンビニの店長やったこともあります。
DSSTNE (pronounced "Destiny") is an open source software library for training and deploying recommendation models with sparse inputs, fully connected hidden layers, and sparse outputs. Models with weight matrices that are too large for a single GPU can still be trained on a single host. DSSTNE has been used at Amazon to generate personalized product recommendations for our customers at Amazon's sc
いま注目すべきシリコンバレーの有名なIT企業は新規のデザインや機能が有効かどうかを検証するためにA/Bテストを行っています。 その一方で、日本の企業も含め、A/Bテストを本番環境で導入している企業は非常に少ないです。 加えて、日本で言われているA/Bテストと海外で言われているA/Bテストは少々異なるものだと感じています。 日本のA/Bテストはフォームの最適化やデザインの修正にとどまっている一方で、海外のA/Bテストはプロダクト開発のサイクルの一部分となっています。 プロダクト開発のサイクルの一部としてA/Bテストを取り入れるためには、大量のテストを定常的に回していく仕組みが必要となってきます。 そこでデータドリブンであると言われているようなシリコンバレーのIT企業は自社でA/Bテストの基盤を作成しています。 今回は社内A/Bテスト勉強会で発表するために、シリコンバレーの有名IT企業がどのよ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」=「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
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
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
強いチームを作るには時間がかかる~強いチームのつくり方(前編)。Developers Summit 2016 業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。 では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016(通称デブサミ)で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。 いまお読みの記事は前編です。 プロジェクトの多くは技術ではなく人間系で失敗している 吉羽 龍太郎氏(Ryuzee.com)。 吉羽と申します。いままで野村総
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く