ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
テストなんか書かなくて良い 僕の考えるサービス開発の肝 - mosa_siru’s blog
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016
強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016 業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。 では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016（通称デブサミ）で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。 いまお読みの記事は前編です。 プロジェクトの多くは技術ではなく人間系で失敗している 吉羽 龍太郎氏（Ryuzee.com）。 吉羽と申します。いままで野村総
【資料公開】DevOpsの基本
こんにちは。@ryuzeeです。 営業でDevOpsの基本の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日本語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の「個別プロセス」の話でしかないので、物理的に一日に10回デプロイボタンが押せても、意思決定から価値化までの時間は長い、ということがありえます。 Build・Measure・Learnの
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。 そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。 そこには、アジャイル開発の延長線上にあるDevOpsを成功させる組織と技術、そしてマインドのあり方が紹介されていました。セッションの内容をダイジェストで紹介
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ
かるび（@karub_imalive)です。 【2016年7月15日更新】 今日はウツを患って2年前に会社を去り、今は資格試験で再起を図ろうとしている昔の仲間と飲んできた帰りなので、少しグチっぽくなりますが勘弁してください。 システム開発会社で一般に普及している業務形態として、超大手から零細企業まで、「客先常駐勤務」という、いわゆる「派遣」的な働き方があります。これをどうにかしてもうやめられないか、という話です。 僕は、長年この業界でエンジニアから営業職、採用職といろいろ立場を替えて10年以上働いてきました。実際自分が体験して、また仲間を現場に送りこむ立場になって思うのは、この「客先常駐」という働き方は働き手にあまりに負荷をかけるのではないかということです。 客先常駐の成り立ちは1960年代 客先常駐っていう形態は、古くは1960年代後半の大型汎用機での開発黎明期にCSKという会社（現SC
リードエンジニアを３ヶ月やって得た開発マネジメントに関する教訓 - seri::diary
ここ３ヶ月ぐらい同じRails案件でリードエンジニアとして仕事をしています。 何気にマネジメント的なことをやるのが初めてだったので色々と戸惑うことがありましたが、だいぶ慣れてきて知見が溜まってきたので、自分のしごとの振り返りも兼ねてまとめておきます。 リードエンジニアのお仕事とは 会社やチームによって全くと言っていいぐらい異なると思いますが、私の場合は以下の様なことをしてきました。 開発スタート時 要件確認 仕様書を読んで全体像やどこから着手するかなどを考える Railsアプリのベース部分の実装 rails new DB周りの設定 初期モデルクラスをDB定義に基づいて作成 factoryも使いそうなものについてのみ作成 rspec、rails_config等諸々の設定 ローカル環境動作用のseedsを整備 使いたいGemを追加 共通で使うCoffeeScriptのライブラリを思いつく限り実
MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
必殺！Github導入に向けて上司を説得する時に使える資料まとめ · DQNEO日記
Subversion vs Github 青い線と赤い線。 あなたの会社は、どちらと運命をともにしたいでしょうか？ 業界誌でも大きく特集されている 「Githubは世界標準の開発環境である（ｷﾘｯ」by @HIROCASTER さん Githubを導入している先進企業たち 公開されている情報をもとにリストアップしてみました。 ご要望があれば追加します！ (Piece of Cakeさんを追加しました。） (サイボウズさんを追加しました。） これらの事例の中から資料をキリハリして、上司の説得に使いましょう。 ＼（サイボウズ）／ ＼（ペイパーボーイ）／ 技術的なアプローチを強化しようと、エンジニアのトップであるmizzyに 直属になってもらい、全社的に取り組むべき課題とチャレンジしたいことの洗い出しや 技術のアウトプットを高めるための取り組みを始めました。 [中略] そのような取組の結果、エン
AngularJSの便利なツール20選 | POSTD
皆さんはAngularJSに興味がありますか？ この記事では、AngularJSのための最適なツールと選りすぐりの情報をリストにまとめています。Angularを使ってアプリケーションの開発をする際には役立つ内容です。 Webアプリケーションを動的に設計したいWeb開発者の多くは、 フレームワークとしてAngularJSを選択するようになってきました 。AngularJSの開発者が新たにAngularJSプロジェクトを立ち上げる場合、本格的にWebサイトを開発しようとすると、非常に多くのツールが必要になります。 AngularJS初心者の場合は、まず始めに AngularJSの良書 を何冊か読むと良いでしょう。 私たちは、オンラインでAngularJSを学習するための、膨大な AngularJSのチュートリアル リストも作成しています。 AngularJSでWebアプリケーションを開発する際
コラム - 技術者のためのほにゃららら | 第23回 「Ruby市場は本当に伸びているのか？数字から読み取る市場成長率の実際」｜CTC教育サービス 研修/トレーニング
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes 第23回 「Ruby市場は本当に伸びているのか？数字から読み取る市場成長率の実際」 (吉政忠志) 2015年3月 改めまして、このコラムを担当する吉政創成の吉政でございます。CTC教育サービスのマーケティング支援を行っているご縁から、この「技術者のほにゃららら」というコラムを月刊連載しています。「ほにゃららら」というのは40歳前後以上の方でないとぴんと来ないかもしれません。「XXXXX」や「なんとか」のような意味です。ちょっと大きな会社の役員をしていたこともあり、技術者の面接で経験したことや、XMLやLinux、Ruby、Ruby on Rails、PHPの認定試験を運営支援する中で感じたことなど、技術者の方々に役に立つような内容を中心に書いて
Javaのマイクロフレームワーク ― この新トレンドは見逃せない | POSTD
この記事は、JavaとScalaの例外分析・パフォーマンス監視のツール Takapi の blog に投稿されたものです。 Javaのマイクロフレームワークとは何か、推奨される理由とは？ どんなプログラミング言語にも、長所と短所はあるものです。例えばJavaは、安全性の高さや、厳しいテストを経ていること、後方互換性などの利点を持つ言語です。しかし、その代償として、アジリティ（俊敏性）や合理性といった面が少なからず犠牲になっています。冗長で、Java自体が肥大化しているという事実も否定できません。とはいえ、新規開発や大規模な開発を行いたい場合、JVM（Java仮想マシン）はバックエンドとして非常に魅力的です。JVMはパワフルな上に、非常に厳しい環境でテストされています。このような利点があるため、結果的にJavaは広く使用され、積極的にデプロイされているのです。 しかし、このJavaの現状を皆
GitHubでコードを「公開しない」リスク？サイバーエージェント流、OSS時代の開発哲学 | SELECK
今回のソリューション：【GitHub（ギットハブ）】 〜「GitHub」でソースコードを社内・社外に公開し、オープンなコラボレーションを実現した事例〜 数々のサービスを生み出し続けるエンジニアリング集団、株式会社サイバーエージェント。そのエンジニアリング文化の中心には、「GitHub」を活用したオープンなコラボレーションがある。 同社ではプロダクトのソースコードは可能な限り全社公開すると同時に、 「スターインセンティブ制度」というリポジトリのスター数に応じたインセンティブを与える制度により、自身の書いたコードを社外へ公開することを推奨している。 ▼そもそもGitHubって何？という方はこちらの記事もどうぞ！ チーム開発を変える「GitHub」とは？導入方法・使い方を徹底解説！【第1回】【導入編】 ソースコードを可能な限り公開していくという流れは、ITベンチャーのみならず世界的大企業にも派生
早く知っておけば良かったrailsの技 | dev.wan.co
rails 自分が rails をさわり始めたときはバージョン1からバージョン2に変わるあたりだったのですが、バージョン2が出た年を振り返るとなんと2007年でした。 月日の流れが速い事に驚く中、早く知ってたら良かったのになぁって事をつらつらとまとめてみました。 最近 rails さわり始めてみたよ！って方の参考になれば良いなと思います。 今回は便利な gem とかではなく、素のrailsで出来ることを挙げています。 ちなみにバージョンは以下の環境です。 About your application's environment Ruby version 2.1.3-p242 (x86_64-darwin14.0) RubyGems version 2.2.2 Rack version 1.5 Rails version 4.1.8 rails new したときの app 以下のディレクトリ
エンジニアの「できない」という言葉の裏側 - Konifar's WIP
「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり
開発スピードと技術的負債 - oinume journal
よくある「開発スピードを優先させるか技術的負債をなるべく発生させないようにするか」という議論、ケースバイケースだとは思うけど、ことプロダクトの立ち上げ段階では、悩んだら「開発スピード」を優先させるようにするべきだと自分は思ってる。 理由は 市場は待ってくれないから。どんなにいいプロダクトでもユーザーに使われなくては意味がないのと、プロダクトを取り巻く外部の環境(競合プロダクトや市場でのニーズ)は自分ではコントロールできないものなのに対して、技術的負債については適切に管理されていればコントロールしながら返済できるから。もちろんバランスも重要だとは思うので、どんな技術的負債も生み出していいかと言われるとそうではないけど。 というわけで自分は「ああこれクソコードだけど機能は満たしてるからそのままリリースしたいなぁ」というのはだいたいクソコードのままリリースしています。(こうやって免罪符を作ってい
数々のエンジニアリングチームを導いた人物がマネジメントの中から学んだ教訓とは？
多くの人が集まる企業やプロジェクトチームをまとめ、率いていくことは多くの困難がつきまとうものです。生き物のように変化する状況に合わせて対応をとることがリーダーには求められるわけですが、そんな仕事で重要なポイントについて、過去にYahoo！やLoudcloudといった名だたる企業でチームを作り、率いてきたティム・ハウズ氏がノウハウを語っています。 What I Learned Scaling Engineering Teams Through Euphoria and Horror - First Round Review http://firstround.com/review/what-i-learned-scaling-engineering-teams-through-euphoria-and-horror/ 「私はこれまでさまざまなエンジニアリングチームに携わり、陶酔感に包まれてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フリーランスの道しるべ - Powered by Crowdtech
http://creive.me/archives/5818/
