はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Webサービスを10日以内にリリースする方法をすべて書いたよ（「Gumad」編） - パパパパ
このブログは、僕がこれまでWebサービスを30くらい作ってきて、失敗したり成功したり色々体験していることをまとめています。 「Gumad β」は株式会社メーヴェの安宅（ディレクター）と杉本（エンジニア）の2人で、Gumroadの存在を知ってから9日間で作ったWebサービスです。作っている間にあったできごとや僕らの動きを公開したら、これから個人やベンチャーの人たちがWebサービスを作る人の（良い意味でも悪い意味でも）参考になるかもということで、少々こっ恥ずかしいですがブログに書き残しておこうと思います。 ちなみに、今回のシステム関連の話は「Gumadβで使ったgemまとめ」こちらに詳しく書かれています。 いまは「Gumad β」はミニWebサービス的な位置づけですが、もしGumroadやその周辺のサービスが盛り上がってくれば、面白い展開ができると考えており、ベンチャーらしく短期間でゲリラ的に
非 Rubyist に送る、失敗しない ruby 実行環境構築方法 - tomykaira makes love with codes
OS や、動かしたいアプリケーションに依りますが、ruby の実行環境の構築は大変です。 というのも、ruby 本体、rubygems、各 gem などのバージョン指定が交錯していて、ruby の ecosystem に慣れていない人にとっては、なにがなんだかわからないからです。 こっちのツールを動かそうとすると、こっちが動かなくなる、みたいなことになります。rubyists は、バージョンの問題を吸収するためのツールを使ってこの問題に対処していますが、ruby に詳しくなくて、ただ ruby 製のツール(たとえば Redmine)を使おうとしている人は分からないでしょう。 そういう人が ruby に挫折しないように、事実無根な中傷をしないように、最近流行のツールで、バージョンミスマッチの問題をおこさない方法を説明します。この説明が対象としているのは UNIX,LINUX 系の環境だ
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
スマホ案件の見積もりについて - ku-sukeのブログ
Android案件の見積り ｜ クラスメソッド開発ブログ を読んで、業界人らしき人のブコメが、「この程度でホッテントリか」という感じで、僕もややそっちよりの意見だったので、ざっくり補足できそうな点について書いて見ました。もう転職して受託の立場ではなくなったので。やや発注側の視点も含まれています。 責任のないリスクについてコスト負担範囲を決める すべてにおいて最重要項目です。変化の激しいスマホ業界においては、互いのリスクテイクについての認識をあわせておく必要があります。例としてはこんなものがあります。 開発期間中に突如OSのメジャーバージョンアップがあった。 顧客「あ、新しいのでましたね。対応できますよね＾＾」 世論に応じて機能の根幹部分が突然リジェクト対象になる。 りんご「今日から電話番号認証禁止ね＾＾直さないと削除しちゃうよ＾＾」 過去を顧みない方針転換がなされる ぐぐる「メニューボタン
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
アリエル・ネットワークでアルバイトをしてきました - forest book
3ヶ月半という短い期間でしたが、アリエル・ネットワーク (以下アリエル) でプログラマーとしてアルバイトしてきました。 よく見かける、どこそこでインターンシップをしてきました風な記事を書いてみます。普通はそういった記事を学生さんが書いているものですが、この記事は普通の無職の人が書いています。 最終日に「開発方法論提案 改めアリエル開発の所感」というタイトルで発表しました。 私が過去にいくつかの会社で働いてきた中で、アリエル開発で改善したら良いと思うことがあったら提案してほしいと言われていました。とはいえ、私の経験よりもアリエル開発の方がずっとレベルが高かったため、釈迦に説法な気がして、そんなタイトルに落ち着きました。この記事では、その内容からいくつか抜き出して紹介します。 私がやったこと アリエル・エンタープライズ という Web アプリなグループウェアの開発に携わりました。 Trac で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
