フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
一休の現在と、ここまでの道のり
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
「JVM Operation Casual Talks」発表資料のリンクをまとめてみる #jvmcasual - 元RX-7乗りの適当な日々
4/7に、LINEさんのオフィスで開催された「JVM Operation Casual Talks」。 一部で、Cassandra Casualだったのではないかという疑惑もありましたが、なかなかためになる話が多くて、あとできっと資料を見たくなる日が来そうなので、ちょっとまとめておこうと思う。 こちらもあわせて読みたい JVM Operation Casual Talks #jvmcasual - Togetter Understanding Memory Management of JavaVM in 15 minutes (@stanakaさん) https://speakerdeck.com/stanaka/understanding-memory-management-of-javavm-in-15-minutes @stanakaさん、どこでJVM使ってるのかと思ったら、今日は
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
ピクシブでの開発 - 金髪の神エンジニア、kamipoさんに開発の全てを教わった話
爆速で成長していた、ベンチャー企業ピクシブ 面接の時の話はこちら=>ピクシブに入るときの話 そんな訳で、ピクシブでアルバイトとして働くこととなった私は、初出勤の日を迎えた。 （↑ピクシブのユニークなオフィス） ほぼ何も分からず始まった開発 プログラミングスキルはほぼ無く、やることも決まっていなかった私は、早速開発の統括をしていたCTOの青木さんからの指示を仰いだ。
デブサミ2014「グリーを支えるデータ分析基盤の過去と現在」講演メモ #devsumi - 元RX-7乗りの適当な日々
どこもそれなりに苦労・工夫しているよなぁと、興味深く聞かせていただきました。 「グリーを支えるデータ分析基盤の過去と現在」 橋本 泰一 氏 グリー 10年ほど東工大で助手・特任准教授した後、2012年にグリーにジョイン 過去の話(2011年) Webサーバからログをrsyncでストレージへ バッチ処理で集計してDBへ(MySQL) ストレージもDBもハードウェアはSolaris Sun Fire X4540 だんだん困ってきた データがほしい人が増えてきた サービスや人が増えてきた データ提供が正直しんどくなってきた 今の話: コンセプト Accessability だれでも自由に Scalability どれだけ貯めこんでも グリーのデータ分析基盤 ゲーム Treasure Data ベース ゲームへのアクセスログ GREE Platform Hadoopベース ゲームからAPIへのログ
スマホUI考（番外編） UIやUXを劇的に改善する、『ビッグオー駆動型開発』とは | fladdict
いま『ビッグオー駆動型開発』とよばれる開発手法が、業界の一部で注目を集めている。 その理由は非常にシンプルだ。『ビッグオー』は非常に安価で簡単な手法でありながら、従来の開発手法に比べ劇的にUIやUXを改善できるためである。 製品コンセプトのような上流から、ボタンのレイアウトといった下流工程、さらにはグロースハックやプロモといったリリース後のフェイズまで一つの手法でユーザビリティを評価できる。この汎用性がビッグオー駆動開発の大きな特徴であり、導入時の利点となる。 今回はこのビッグオー、の概要と具体的なやり方について論じたい。TwitterのUI拡張予言以来、久しぶりのUI系エントリである。 ビッグオー駆動開発とは何か？ ビッグオー駆動開発は、正式には『OKAN Driven Development（オカン駆動型開発）』とよばれる開発手法である。 これは自分のオカンを指標とすることで、低コスト
Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ
開発合宿でDevOps界隈やモニタリング界隈で流行りのツールを組み合わせてBlue Green Deploymentできる何かを作りました。 同じチームで開発したid:shiba_yu36 先生やid:wtatsuru 先生が既にブログを書いてますが、自分の視点で書いてみます。（13/12/24追記: より詳細な内容が新規に書かれたのでリンク先を入れ替えました） Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; Docker コンテナにアプリケーションを立てて Graphite でいい感じに可視化するまで - wtatsuru's blog 僕は主に、各ツールから得られる情報をまとめて管理し、デプロイを実行するデプロイ管理ツールを作成していましたので、それについて書きます。 普段は運用の修行をして
【島国大和】ゲームはこうしてダメになる。横ヤリ刺さって死屍累々。
【島国大和】ゲームはこうしてダメになる。横ヤリ刺さって死屍累々。 ライター：島国大和 島国大和 / 不景気の波にもがく，正体はそっとしておいて欲しいゲーム開発者 島国大和のド畜生 出張所ブログ：http://dochikushow.blog3.fc2.com/ どうも，島国大和です。 デスマーチ，してますか？ 前回，「ゲームを作る立場で，どうやって落とし穴を回避するかを考えるよ。」と題して，ゲームを開発していくうえでハマりやすい罠を，どうやって回避するのかといったことを書きました。 今回はその続き，というか，そこで書き切れなかったことをまとめてみたいと思います。テーマは，「なぜ横ヤリは入るのか」ということ。 ゲームが大失敗する理由の中で，かなり大きいのが，偉い人からの横ヤリです。完成品を見て「ここちょっと，こうすべきじゃない？」みたいな。 ここではなぜ横ヤリが入るのか，それがどうしてダメー
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
livedoor Techブログ : なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ
こんにちは、ライブドア技術部会の櫛井です。 Webサービスの高速化に取り組んでいる全てのエンジニアに存分にその腕をふるってもらうべく、ライブドアがサーバ100台を準備してイベントを行います。いい感じにスピードアップコンテスト、略して ISU Contest (Iikanjini Speed Up Contest) #isucon です！レギュレーション事前公開、細かいルール無用のチームバトル。腕に覚えのあるエンジニアにはぜひ参加していただきたい！ なお、参加者募集の開始は7月28〜29日頃を予定しています。Ustream等による中継はございませんので、ぜひ直接ご参加ください！ レギュレーション概要 レギュレーション詳細は後日、参加募集の際に全て発表します。現状は概要のみでご容赦ください。また詳細が変更される場合があります。(参加応募開始時に公開するものからは変更されません。) ライブドアが
Webアプリケーションエンジニアはノマドであれ（特定のサーバに依存しない方法） - blog.nomadscafe.jp
弊社では毎週水曜日はノーエンジニアデーなので、最近はMacbook AirとWIMAX持って外で仕事しています。意外と快適ですが、ここで書くのはサーバの使い方の話です。 ときおり、次のような状況に遭遇することがあります。 開発環境して使っているけど、セットアップをどのように行ったか残っていないので、新サーバへ移動できない 本番環境だけど、セットアップをどのように行ったかわ(ry デプロイ元／管理ツールサーバとして使っているので古いサーバだけど捨てることができない DBがどこから参照されているか管理できていないので、サーバの入れ替えが困難 コードがどこから参照が把握できていないので、容易にサーバ構成の変更ができない 椅子^H^H 一度設置したサーバの移動なんてなかなかすることないと思う人はいるかもしれないけど、サーバが何の警告もなしに突然壊れて入れ替える必要がでてくるのはもちろん、インフラ技
overlasting.net
overlasting.net 2019 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
The missing package manager for macOS (or Linux) — Homebrew
Redirecting... Click here if you are not redirected.
hide-k.net#blog: 巻き込み重要
新しい会社に入って３ヶ月が過ぎて、ようやく試雇採用期間も終わり無事正式採用されました。 周りは若い人ばっかりで、なかなか活気があるのですが残念ながら業務の仕組みややり方が古いのも、また事実。僕が思うくらいだから、結構古い。というかベンチャーにありがちな勢いで来ちゃった感じ。 一人、新しいことに敏感な方がいらっしゃるのだが、なかなか忙しい人なので周りを巻き込むまでには至ってなかった感じ。 まぁ、そこはそこ。まだ小回りが利くうちに変えちゃえってことで、勝手気ままに色々巻き込んじゃった。 IRC 元々あって、僕が来たときには結構ログ流れてたんだけど、その前は全然使われてなかった感じだった。くだらないことから何から片っ端から流し始めてマネージャーにも強制参加させたら、みんなちゃんと使うようになった。 wiki 部内wikiみたいなのが元々あったんだけど、ちょっと停滞気味な感じは否めなかったの
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
「サービスは半日で完成させる」—— SETAKE・たつをさん
「有名人身長推定サイト SETAKE」「EREK」などのサービスを作ったたつをさんはドメイン取得からサービスリリースまでは半日でこなすという。飲み会で生まれたアイデアをもとにサービスを開発することもあるため、ペンはどこにでも持ち歩く工夫をしている。 「ひとりで作るネットサービス」第11回目は、Web APIを活用して次々と小粋なサービスを開発するたつをさん（35）にお話をうかがった。「ドメイン登録からサービスリリースまで半日が目安」と言い切る彼は、どのように企画・開発・運用を行っているのか。その秘訣に迫った。 飲み会の会話から「有名人身長推定サイト」が生まれた 「作ったものはたくさんの人に使ってもらいたいですよ。エンジニアですから」と話すたつをさん。彼が作るサービスはWeb APIを使ったシンプルなものが多い。ちょっとしたアイデアが、情報の見せ方を工夫することで“意外と便利”なサービスにな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
個人開発と徳
Google Code Archive - Long-term storage for Google Code Project Hosting.
Technologies for UI