ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。 --だとすると、日本のSI業界というのは将来性があるのでしょうか? わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。 「情
自分ところの新人向けこんなことをするといいよーとメモ書きしてたら結構な量になってきたのでブログに晒してみます。大きくインプットとアウトプットに分けて書いてます。 アウトプット インプットよりアウトプット大事!ということでアウトプットからいきます。 コードを書こう なにはともあれ。 Shut the fuck up and write some code ぐだぐだ言ってないでコード書けよ、ハゲ後ほど紹介する「Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)」に載っている言葉です。 まぁ、載っているというかプログラマー界隈で良く言われる言葉です。 仕事で書くだけだと足りないのでプライベートでもガシガシ書きましょう。そして晒しましょう。 別にアプリである必要もありません。僕はこんなの書いたりしてます。 Google Apps Sc
技術部の福森です。 クックパッドでは RSpec と Jenkins を利用して CI による自動テストを行なっています。 テストの数は 12000 examples を越えていて、テストによっては稀に失敗する物が出てきています: 時間帯依存で失敗してしまうもの 他に同時に実行されるテストに依存しているもの (並列実行で組合せが変わり再現する) インテグレーションテストでの ajax リクエストの微妙なタイムアウト etc また、本番環境を壊さないよう、 CI で成功したリビジョンのみデプロイ可能となっており、開発者が push しデプロイしたいと思っている時に無関係な原因で失敗する事を避けたいという欲求があります。 なぜなら、再度ビルドを実行する時間 (およそ 10 分) の間待たされる事になるからです。 そこで、そのようなテスト起因での失敗を減らし、かつ開発者にそれらを修正してもらうた
このところ海外(おもに米国)のスタートアップで、「full stack engineer」の求人広告を以前より多く見かけるようになりました。フルスタックエンジニア、つまりインフラからミドルウェア、モバイル、デザインまで、あるいは設計からプログラミング、デプロイまで、何でもこなせるエンジニアを募集している、ということのようです。 例えば、このPublickeyでも導入しているコメントシステムの開発元であるDisqusは現在、「Full-stack Web Engineer」を募集しています。 「What We're Looking For」の項目では、5年以上のエンジニア経験とチームリーダーの経験などを求めた上で、技術的には次のような要件を並べています。 Very experienced with web application deployment and software design
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 (家族や友人などプログラムを知っていない人間に話しても分からない、という事もある) プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか? 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか?」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 優秀なプログラマーであるためには、自分の持つスキル、経験、知識から、動くコードを生産するための資質を持っている必要がある。技術的なスキルは持っていても、必要な資質を持っていないために優秀なプログラマーになれない人もいる。この記事では、偉大なプログラマーになるために必要な7つの資質を紹介する。 1.自発的に新しい技術的・非技術的スキルを習得する だめなプログラマーは、どうしても必要になった時にしか学ぼうとしない。よいプログラマーは、積極的に新しい技術的スキルを習得する。偉大なプログラマーは自ら新しい技術的なスキルを学ぶだけでなく、技術以外のスキルも学び、ほかの人なら考えもしないような情報源に対してもオープンな態度で接する。 具体的に例を挙
先日「飲み会版ソーシャルランチをつくってみた」を書いた者です。 上の記事では、僕がつくった「飲活」というサービスの説明が大半で、どうやってつくったのかとか説明が少なかったので、今回はそれについて書いてみようかと思います。 まずは僕についてさらっと。web、スマホアプリ開発の会社に入社。それまで他会社でwebサービス、iPhoneアプリの開発。ガチ文系php、objective-cを基本的な動作を実現させられる程度 (高度なことやるときはコピペだもん!)webサービスのプログラムを書いたり、iPhoneアプリをつくったりしてます好きな女性芸能人はミムラと橋本愛ちゃん。愛ちゃんなんで夜更かししちゃったの!失敗僕は「「飲活」」を作るまでも、iPhoneアプリを開発したり、webサービスのメンテナンスをしたりとプログラミングをしておりました。 なので、プログラミング初心者というわけではありません。
您的请求在Web服务器中没有找到对应的站点! 可能原因: 您没有将此域名或IP绑定到对应站点! 配置文件未生效! 如何解决: 检查是否已经绑定到对应站点,若确认已绑定,请尝试重载Web服务; 检查端口是否正确; 若您使用了CDN产品,请尝试清除CDN缓存; 普通网站访客,请联系网站管理员;
git pullは使わなくてもよい 初心者はgit pullを使わない方がよい 我々ソフトウェアエンジニアは勉強が大好きなので、コマンドがあるとそれを勉強して使いこなさなければいけないと考えがちですが、ときには「覚えない、使わない」という発想も大事なのではないでしょうか。 以下にその理由をのべます。 git pullは使う必要がない git pullを使わないとできないこと、というのはありません。 使わなくても全然困りません。 git fetchとgit mergeとgit rebaseだけですべての用は足せます。 私はチーム開発でGitを本格的に使い始めて数か月経ちますが、普段の作業でgit pullを使ったことはないしそれで困ったこともありません。 git pullを使わなければ、余計な落とし穴に落ちない git pullには落とし穴があります。 初心者はたいていその穴に落ちます。 「
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら: http://nvie.com/posts/a-successful-git-branching-model/ (翻訳の公開と画像の利用は本人より許諾済みです) このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト(仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
平素よりイベントカレンダー+ログをご利用いただき、誠にありがとうございます。 イベントカレンダー+ログは「IT・製造業・ビジネス関係のイベント(セミナー・展示会・勉強会・コンテスト・Webイベントなど)を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー+ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年6月30日(火)15:00をもちましてイベントカレンダー+ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら
前回の記事でGitHubとJenkinsを用いた自動デプロイ環境の概要をご説明しました。 GitHubやJenkinsと連携した開発環境作成でのrsyncとの出会い 今回は、その環境を実現するための設定手順を書いて行きたいと思います。 大きく4つの手順があります。 Jenkinsのインストール Apacheの設定 JenkinsとGitHubの連携 自動デプロイ設定 開発環境 ・CentOS 6.2 ・Apache がインストール済み Jenkinsのインストール まずは、Jenkinsのインストール 通常ならば、運用するサーバとJenkinsが動いているサーバを分けるべきですが、サーバコストの都合などで今回は同一サーバ上で動かすことにします。 ApacheサーバとJenkinsサーバが同じport80で待つことはできないので、jenkinsをport:8080で動かすことにします。 また
概要 現状、適用する開発手法に関しては、各プロジェクトに任されているため、特定の開発手法を採用していないプロジェクトも多い。しかしながら、一定規模の開発をする場合、何かしらの開発手法を採用した方が良いのは自明である。担当プロジェクトにおいて近年注目されているSCRUMを適用して開発を行ったが、導入時に戸惑うことや疑問に思うことがあった。本稿では、実際にプロジェクトでSCRUMの手法を適用した際の具体的な方法、手順、独自の工夫などについて整理する。SCRUM開発を導入する際の一つのやり方として参考にしていただきたい。 目次 序論 社内ではデカグラフ戦略に伴い、新規プロジェクトが大量に立ち上がっている状況である。現状では、適用する開発手法に関しては、各プロジェクトに任されているため、特定の開発手法を採用していないプロジェクトも多い。しかしながら、新規開発などで、一定規模の開発をする場合、何かし
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Ruby on Rails をこれから始める人向けの情報 Ruby on Rails をこれから始めたいのですが、どんな本がおすすめですか?と聞かれたので、ちょっとまとめておきたいと思います。 » 僕が Ruby on Rails を絶賛する理由 - 僕は発展途上技術者 というエントリーを2007年に書きましたが、その後状況はいろいろと変わり、僕自身 iOS アプリや Android アプリを開発するようになったり、Web サービスでも Python on GAE を触るようになったりして、当時ほど Ruby on Rails 一色というわけではなくなりました。 また、Ruby on Rails の環境を自分の開発マシンに用意するのも » Mac OS X 10.8 Mountain Lion に Ruby on Rails 環境をセットアップする - 僕は発展途上技術者 で書いたように、
これまでにない全く新しいものを生み出す時や未知なる領域の問題を解決しようとする時、複数の人でのコラボレーションが重要になりますが、「コラボレーション・パターン」はそうやって複数の人間が一つのことに取り組む際に、アイデアを積極的に出し合い、メンバーが互いを高めあいながら、個人では考えられなかったような結果を出すことができるようパタン・ランゲージの考え方に基づいて作られた34項目。対立や分裂で破滅的な結果が起こることもある集団での作業を、ポジティブな結果に昇華させます。 コラボレーション・パターン ― 創造的コラボレーションのためのパターン・ランゲージ http://collabpatterns.sfc.keio.ac.jp/index.html コラボレーション・パターンは全部で34項目あるのですが、パターンは大きくわけて「未来への使命感」「方法のイノベーション」「伝説を作る」の3つのまとま
みなさんこんにちは。@ryuzeeです。 Allan Shalloway氏のMindsets: Waterfall, 1st & 2nd Generation Agileがとても素晴らしい記事だったので、ご本人の承諾を得て一部日本語訳で紹介します。 なお、氏がかかれたこちらの記事(拙訳)を先に読むと理解が深まると思います。 以下の表は、ウォーターフォールとAgile(第一世代、第二世代に分けた。)におけるマインドセットを表にしたものである。誤解されないようにしてほしいのは、どのマインドセットが正しいとか正しくないとかいうことは無いということである。 我々はもっと仕事をうまくやるために、マインドセットを自由に持ち、変化していくことが必要かもしれない。 ただし自分自身を変化させることは難しいし、ましてや他人を変化させることはもっと難しい。 第1世代アジャイルと第2世代アジャイルの類似点
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く