サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
second2none.hatenablog.com
起業して2年がたった。 2016年は自分にとってとても厳しい年であったが、たくさんの学びが結果として得られたのだ、と思うために、自分を振り返ることにした。 結果として、「期待に応えようとしすぎて自爆する1年」だった、というのが現状の結論だ。 価値創造にコミットしすぎると爆発する ビジネスの対価を得る=顧客に価値をもたらす の図式を頭にもっておくことは重要 「価値を出せていないからお金をもらってはいけない」の呪縛 ただ、2年目の僕はこの考え方にはまりすぎた。 「価値を出せていないからお金をもらってはいけない」の呪縛にとらわれてしまったのだ。 私は、次第にこんな考え方にとらわれすぎて、仕事を受けるようになってしまった。 ホームページを運用したところでこの顧客にはあまりメリットが少ないのだから、運用費用をとったら悪いなぁ・・・ このシステムを3年でペイさせるなら、このくらいの金額でやらないと・・
最近、研ぎ澄まされた仕事をしていない。 そんなことをふと思った。 いや、多分最大限の仕事をしているのだが、逆に言うと「最大限以上」の仕事をできていないのではないかと。 自分のできないことをしたり、自分の殻を破らなければ到達できないような、ヒリヒリした状況に自分の身を置けていないのではないか。 「小高の少数力」を発行したが、私をよく知る友人からは「つまらない」と一蹴されてしまった。 小さくまとめてしまったような気がする、という思いは自分のどこかにもあったのだ。だからそう言われた瞬間にすぐ何がいけないのか納得した。 出来ないことに挑戦し続けなければ、成長はないし、誰もやりたがらないことを楽しそうにやっていなければ、私じゃない。 そんな反省をした。
先日までの3連休で開発合宿を開催しました。 今回の開催で3回目になります。 秩父でやりました。 やったのはここ http://www.sports-no-mori.jp/ インターネットがつながる コテージがそこそこ広くてみんなで集まれる まぁまぁ安い 温泉がある という理由からココにしたのですが・・・ インターネットつながらない!! という衝撃の事態が発生。1日目はなんだかんだで 疲れていたりご飯を食べたりだったので ほとんどマッサージをする会のようになっていました(笑 2日目の朝に直ると言われましたが、 直らなかったので、残念ですがキャンセルして帰りました。 メンバーの家で続きを 帰った後はメンバーの家で続きをやったんですが、みんなはあまり 集中できなかったようです。 私は一人もくもくとAndroidの開発を比較的集中して出来ましたが。 自分のスマホでジェスチャーイベントを感知してメッ
結局何したのか 2月 色んな所に顔出し。面白いことがあったら飛び乗ってみた。手続き等グダる。 3月 面白そうだから南相馬でやってみようと決意。その後約1ヶ月先方音沙汰がなく手持ち無沙汰になって焦る 4月 しょうがないのでコンティンジェンシープランを考えだす。先方に決断要求を改めてする。 5月 ちょこちょこ動き始める。自分の+南相馬サイドでも仕事もいくつかもらう。自分が提案した案件が始めて通る 6月 ↑の案件をこなしながら始めての請求書 7月 埒もあかないし貯金もあんまり無いのではよお金の出し方決めろと言わんばかりに南相馬に突撃 ←今ココ なぜそうしたのか 割と聞かれるのが「丹後にいくのではなく南相馬でやることにしたのか」という質問。 僕が退職するタイミングでは京都の京丹後からもちょっと仕事をしないかみたいな提案をもらっていて、実際に行きましたが環境的にも食事も文化もあるよい地域だったので、
先日、こちらのハッカソンに参加して浪江賞(事実上の最優秀賞)をいただくことが出来ました。 浪江町住民のタブレット活用を考えるハッカソン@福島 http://codeforjapan.doorkeeper.jp/events/11492 このハッカソンで目指したこと このハッカソンで目指したのは本当に価値があると思ったアイデアを、住民の人にも価値があると思ってもらうことでした。 少しだけ個人的な事情を盛り込むと、その上でちゃんと自分の力を発揮し、最優秀賞に選ばれることでした。 過去2回の利用者=審査員型のハッカソンで失敗した経験 利用者=審査員になるハッカソンには、過去2回参加しましたがどちらも大ハズシしていました。 そのため、今回はもっと具体的な顧客をイメージしてそれを訴えかけようということを挑戦しようと思いました。 非エンジニアとして参加するという選択 過去のハッカソンを振り返ったときに
会社の後輩に対して「なにかをできるようになりたいと思うなら、何回でもチャレンジすべきだ」というような話をしたところ、こんなお悩み相談が飛んできました。 「話をきいていて、三日坊主を(何度も)続けるのが自分の課題だと思いました。 あと(それを)どこまでがんばるべきかで悩んでいます」 基本は頑張らなくてもいい 僕はこう返しておきました。 「頑張らなくていいと思うよ。大事なことは、やりたいと思ってるならやりたいと思っているときに何度でも挑戦すべきだってことだと思う」 何かをやれるようになるために相応の努力をしないといけないのは確かですが、いちいち「頑張る」と意気込んでも努力は続かないし、「頑張った」結果うまく行かないと、自分には向いていないではないかと落ち込んでしまいます。 実際、何かをできるようになりたいと思った時に本当にできるレベルに達するためには、たくさんの失敗が必要だと思うのです。そうい
本日付で5年弱務めさせていただいたワークスアプリケーションズを退職しました。 在職中は社内・社外問わずとても沢山の方にお世話になりました。 別に退職エントリなぞもう流行らんだろうとは思ったし、 僕が書くと割と過激な内容になって訴訟リスクが云々とかあると思ってはいるのですが、 まぁ自分の心情の整理も含めて書いてみようかなと思います。 理由とか待遇とかそっちの話がこういうエントリだと多いですが、 私は自分の価値観にフォーカスを当ててみたいと思います。 この記事を読んでくれた人が、自分の価値観について考えるきっかけになればと思います。 ワークスでは何をしていたか ワークスでは、もっぱら品質向上に関わる仕事をしていました。 自動テストに始まり、GUIの製品企画や評価、単体テストの啓蒙、コストの可視化による意識啓蒙、 テスト内容やテスト実行の管理、BTSの導入、Jenkinsを利用したCI、およびそ
AutoHotKeyをご存知でしょうか。 言わずと知れたキーバインドツールなのですが、私はこれを使い倒しています。 これのお陰でマウス操作から解放されるようになるので、日々のストレスがかなり軽減されます。 リモートデスクトップ上では使えない ただし、これってリモートデスクトップ上では使えないんです。 リモートデスクトップ操作ではすべてのコントロールが向こう側の設定に依存するので リモート側の端末にAHKがインストールされていないことには使えないという問題がありました。 でも、共用の端末である以上勝手に私のゴリゴリのキーバインドをインストールするわけにもいかないので、どうしようかと思っていたのですが、AHKはスタンドアローンに出来ることを知り、 快適操作を実現することが出来ました。 ポータブル(standalone)AHKの作り方 適当なディレクトリ(例:AHK)を作成 まず、自分の端末にイ
jenkinsでジョブ名やビルドNoを取得する方法があるだろうなと探してみたら、 環境変数が用意されているようです。 Building a software project - 日本語 - Jenkins Wiki https://wiki.jenkins-ci.org/display/JA/Building+a+software+project
誰か、「仕事は楽しい」と言ってくれ という記事をみて同僚が記事を書いていたので私も一言。 『誰か、「仕事は楽しい」と言ってくれ』 ⇒ めっちゃ楽しいっす!!! | 働くって楽しいぜ! http://enjoy-work.raindrop.jp/archives/1293 個人的には仕事が楽しいかどうかなんていうのは結局自分が決めることだと私は思っています。 根本的にはね。だから誰かが楽しいぜ、なんていってもあんまり意味はないんだろうね。 ただ、そういうマインドセットが出来ていないから筆者は苦しんでいるのだと思うし、 それについてなんらかの解決方法を提示してあげるのが過去に同じ苦しみにいた大人の出来ることだと思ったので少し思い出しながら考えてみました。 自分がどうして人生を楽しくできるようになったか そういえば私も大学生のはじまったときは未来に希望なんて持っていませんでした。 凡庸であり兄に
Jenkinsプラグインの開発にあたって、Jellyの扱い方やメソッドとの関係性の理解に 結構つまったのですが、このページを教えてもらってだいぶ理解が進みました。 Basic guide to Jelly usage in Jenkins - Jenkins - Jenkins Wiki https://wiki.jenkins-ci.org/display/JENKINS/Basic+guide+to+Jelly+usage+in+Jenkins#BasicguidetoJellyusageinJenkins-Otherpredefinedobjects せっかくなので途中までですが簡単に翻訳してみました。 JenkinsでJellyを使うための入門ガイド もしあなたがJellyやJenkinsにあんまり詳しくなくて、プラグインの設定を作成するのが難しいと思うならこれを読むといい。 この
builderパターンの使いどころ 素材がいくつかあって、その順番とか回数とかで結果が変わるようなもの オブジェクトを生成するときにたくさんのパラメータが必要 にはbuilderパターンを使うといい コンストラクタとの使い分け コンストラクタだと、パラメータがふえたときにこんな面倒なことになる コンストラクタのパラメータの順番を覚えてないといけない 必須でないパラメータが存在するので、柔軟にやろうと思うとたくさんのコンストラクタが必要 builderパターンを使えば、この辺の問題が解決する こんな時につかえる フォルダー階層のセットアップ /user/local/bin のようなディレクトリをセットアップするのに使う。 ディレクトリをセットアップしていく上でその存在チェックとかをしてくれるようなbuilderをつくると便利 APIなどでの外部アクセス APIの操作では、必須のパラメータと、
Problem while launching unix Slave http://jenkins.361315.n4.nabble.com/Problem-while-launching-unix-Slave-td391273.html この問題にぶち当たって悩んでいましたが、解決しました。 資料も少ないので、参考になればと思い、書き留めておきます。 日本語で この問題ですが、WindowsのJavaが /tmp/slave.jar のようなパスを解釈できないことによって発生していることがわかりました。 解決方法 Cygwin用にjava Wrapperなるものが提供されているので、それを使用することで解決できます。 これは、Unix JavaとWindows Javaの違いを吸収してくれるので、 先ほどのようなパスを上手く解釈してくれるようになります。 ダウンロードはこちらから。 Cy
InfoTalkに参加してきたので、遅ばせながらレポートを。 InfoTalk - 産業技術大学院大学 http://pk.aiit.ac.jp/index.php?InfoTalk IBMの細川さんによる講演でした。 実際にレビューの実践などをしていただいたのですが、 そのあたりの情報を無闇矢鱈と書くのはよろしく無いので、 自分の感想や調べたことがベースになります。 欠陥を先送りにしないためのレビュー レビューの重要性は「欠陥を先送りにしないために問題を発見すること」です。 例えば要件定義段階における定義の誤りや明快さの欠如は、 コーディングにおけるミスにつながります。 こうした問題の原因を早い段階で「発見することが出来る」のがレビューだと いうような趣旨だったと思います。 あと、細川さんお気に入りのフレーズっぽいので紹介しておきますが 「品質は上流から作り込むと言われていますが、あれは
Play!framework でpjaxを使って見ました。 pushslate とはなんぞや pjax こそが pushState + Ajax の本命 - punitan (a.k.a. punytan) のメモ http://d.hatena.ne.jp/punitan/20110404/1301895279 こちらのサイトが大変参考になりました。 要するに 非同期通信なんだけど、パーマリンクを持ってて進むとか戻るとかのボタンが使えるよ! という非常に抽象的な解釈をしておきます。 上記のpunitan 氏のページでは、perlで実装していましたが、 これをPlay!frameworkで上手いことやってみよう!というものです。 pjaxを使えるようにするまで pjaxを追加する defunkt/jquery-pjax - GitHub https://github.com/defunkt
今日インタビューを受けている中で、「行政(官)と民間(民)の連携はどのようにしていくべきか」という問いがありました。 私としての答えは「まずは行政に頼られる民でならねばならない」としました。 この背景に、小高区復興拠点施設について非常に歯がゆい思いをしたことがあります。 復興拠点施設のワークショップでは、再三に渡り市民とのワークショップが開催されましたが、 土地で敷地が小さくなり、機能的な縮小をしました。 その中で、「中のソフト部分についてはハード以上に市民の声を聞きながら、地域の人たちが運営できるように進めていきたい」という話があったにもかかわらず、 その後一回もワークショップ等が開かれることなく、公営で動き出そうとしています。 小高区復興拠点施設の愛称決定 - 南相馬市 また、今回愛称を募集し、「小高交流センター」という名前に決定していましたが、マーケティングの素人が考えなしに募集し、
「Software Test & Quality Advent Calendar 2011」の12/3エントリーとして書かせていただきます。よろしくお願いします。 私がソフトウェアテストについて勉強をはじめて2年ほどになりますが、今年の1年はさまざまなキーワードに触れたり、取り組んだりすることで考え方が広がったように思います。 今回は、それらについてまとめさせていただく機会にしようと思っています。 ドキュメント・仕様 XDDP/清水吉男氏 Sphinx BlockDiag ドキュメントって、意外と良い書き方やフレームワークについては触れられてないんだな・・・ という印象を持っていたんですが、清水吉男氏のXDDPや書籍「要求を仕様化する技術・表現する技術」 私的に興味深いと思いました。 ドキュメントを書いてもすぐに陳腐化してしまうのは悩ましいところです。。 仕様書とテストを上手く結びつけて管
このページを最初にブックマークしてみませんか?
『右脳系エンジニアのブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く