が、改行が無視されます。
Blogger->IFTTT->EVERNOTEでは改行がちゃんと温存されています。
tw->IFTTT->EVERNOTEで改行無視されてもさほど困りませんが、fbは改行なくなっちゃうとダサいです。（ｘ＿ｘ；）
使ってるIFTTTレシピは、テケトーにツモった先人様制作の出来合いのものです。
そこで、
ifttt
の記事を参考に、IFTTTレシピにpreタグを入れてみました。
うまくいくか…？
2014年8月8日金曜日
facebookからIFTTTでEVERNOTEにライフログ蓄積する際に改行を温存しようと画策するtest
fbやらtwやらBlogger・Pocket・NikeFuel・ToodledoからIFTTTでEVERNOTEへ転送してライフログ化を図っています。
が、改行が無視されます。
Blogger->IFTTT->EVERNOTEでは改行がちゃんと温存されています。
tw->IFTTT->EVERNOTEで改行無視されてもさほど困りませんが、fbは改行なくなっちゃうとダサいです。（ｘ＿ｘ；）
使ってるIFTTTレシピは、テケトーにツモった先人様制作の出来合いのものです。
そこで、
ifttt
の記事を参考に、IFTTTレシピにpreタグを入れてみました。
うまくいくか…？
が、改行が無視されます。
Blogger->IFTTT->EVERNOTEでは改行がちゃんと温存されています。
tw->IFTTT->EVERNOTEで改行無視されてもさほど困りませんが、fbは改行なくなっちゃうとダサいです。（ｘ＿ｘ；）
使ってるIFTTTレシピは、テケトーにツモった先人様制作の出来合いのものです。
そこで、
ifttt
の記事を参考に、IFTTTレシピにpreタグを入れてみました。
うまくいくか…？
しんがりを漢字で書くと…21世紀はカリスマのないリーダーの時代
リーダーとは神輿の上で踊る者でなく神輿を先頭で担ぐものであるみたいな絵がよくあるけど（ピラミッドの石運びでも同じ）、むしろしんがりで担いでるというのが個人的には実感であります。
この案件なんとか社員どうしで話し合って決めてみて、と私が言うのに対し社員がしびれをきらし「もう社長が決めてよ」と言ったときのみ初めて「そっすか？ じゃ…」という感じです。
それは社長が決めてねと社員が言ったんだから社長が決めてもう文句言いっこなしだよね。
しんがりは漢字で「殿」と書くのも故なきことではないとおもうんです。
前面で目立たせてもらってる派手なヤツではなく、実はいちばん後ろにいる地味男くん地味子さんが大ボスだったという。
ときたま最後尾で声を発してなにげに神輿の行方を頑固に支配しております。
最前列で踊りたいやつが、気持ちよーく踊れるように。
元早稲田大学ラグビー部監督の中竹竜二さんもまさにそういうことおっしゃってますね。
これからの組織は変化の早い世の中に即応できるよう現場の個々人の知恵とリーダーシップを引き出した者勝ちであり、そのためにはメンバーのリーダーシップを引き出すフォローに回ることこそ、21世紀のリーダーのコンピテンシであるみたいなことをよく言われますね。
言い換えれば、21世紀はカリスマのないリーダーの時代であるともいえます。
しかし…じつは20世紀の偉大な経営者の多くも、「僕はカリスマがなかった」とおっしゃっています。いやいやあるでしょ、という感じですが、そうした方々がそのような自覚のもとにどのようなリーダーシップを発揮されたか、という思想と手法は、21世紀になっても、いやむしろこうした21世紀だからこそなおさら、充分学ぶべきものがあると考えています。
この案件なんとか社員どうしで話し合って決めてみて、と私が言うのに対し社員がしびれをきらし「もう社長が決めてよ」と言ったときのみ初めて「そっすか？ じゃ…」という感じです。
それは社長が決めてねと社員が言ったんだから社長が決めてもう文句言いっこなしだよね。
しんがりは漢字で「殿」と書くのも故なきことではないとおもうんです。
前面で目立たせてもらってる派手なヤツではなく、実はいちばん後ろにいる地味男くん地味子さんが大ボスだったという。
ときたま最後尾で声を発してなにげに神輿の行方を頑固に支配しております。
最前列で踊りたいやつが、気持ちよーく踊れるように。
元早稲田大学ラグビー部監督の中竹竜二さんもまさにそういうことおっしゃってますね。
- カリスマになろうとして「倍返し」を食らいました
- ｢日本一オーラがない監督｣が成功したワケ
- 中竹竜二さんの、黙ってオレについてきてはいけない！──『選択の時』第4回
- 中竹竜二氏（前編）～組織を劇的に変える「フォロワーシップ」とは？～
これからの組織は変化の早い世の中に即応できるよう現場の個々人の知恵とリーダーシップを引き出した者勝ちであり、そのためにはメンバーのリーダーシップを引き出すフォローに回ることこそ、21世紀のリーダーのコンピテンシであるみたいなことをよく言われますね。
言い換えれば、21世紀はカリスマのないリーダーの時代であるともいえます。
しかし…じつは20世紀の偉大な経営者の多くも、「僕はカリスマがなかった」とおっしゃっています。いやいやあるでしょ、という感じですが、そうした方々がそのような自覚のもとにどのようなリーダーシップを発揮されたか、という思想と手法は、21世紀になっても、いやむしろこうした21世紀だからこそなおさら、充分学ぶべきものがあると考えています。
2014年8月7日木曜日
Redmineのカスタムフィールドからリンクを張れる機能も今じゃ普通に標準装備な件
「Redmineでこんなことができない、とネットで言われてることのかなり多くが、じつは今ではすでに標準機能でできるようになっていた」の顕著な一例を…。
2.5.0 adds a "Link" custom field format but also adds the ability for other custom field formats to render values as a http link to a configurable URL with the following substitution available:
カスタムフィールドのURL欄に文字列やこれらの要素を記述することにより、そのフィールド自身の内容やプロジェクトID・プロジェクト識別子などから組み立てた任意のURLへのリンクを張らせることが可能です。
惜しむらくは、他のフィールドの内容を参照できればもっと良いのに！ という点です。
人間の欲には限りがありませんね。
具体的には、たとえば「FTPサーバアドレス」というプロジェクトカスタムフィールドを作ったとして、その定義において、「値に設定するリンクURL」欄に
と指定しておくと、たとえば
であれば、 「FTPサーバアドレス」フィールドから「ftp://ftp.oreore.oredayo.tokyo/test/」へのリンクが張られます。
しかし実際には、下図でいえば、「FTPログインID」フィールドや「ルートパス」フィールドの内容を合成することができれば、より実用的でしょう。
まあ、この例にかぎっていえば、「FTP URL」というフィールドを作れよ、といわれればそれまでなんですが。
このほかに、カスタムフィールドのデータ型として「リンク」も新設されております。
URLそのものがフィールド内容となる場合にはこちらがお手軽です
2.5.0 adds a "Link" custom field format but also adds the ability for other custom field formats to render values as a http link to a configurable URL with the following substitution available:
- %value% => the custom field value
- %id% => id of the customized object
- %project_id% => id of the project of the customized object if defined
- %project_identifier% => identifier of the project of the customized object if defined
- %m1%, %m2%... => capture groups matches of the custom field regexp if defined
カスタムフィールドのURL欄に文字列やこれらの要素を記述することにより、そのフィールド自身の内容やプロジェクトID・プロジェクト識別子などから組み立てた任意のURLへのリンクを張らせることが可能です。
惜しむらくは、他のフィールドの内容を参照できればもっと良いのに！ という点です。
人間の欲には限りがありませんね。
具体的には、たとえば「FTPサーバアドレス」というプロジェクトカスタムフィールドを作ったとして、その定義において、「値に設定するリンクURL」欄に
- 「FTPサーバアドレス」フィールドの内容が「ftp.oreore.oredayo.tokyo」、
- プロジェクト識別子が「test」
であれば、 「FTPサーバアドレス」フィールドから「ftp://ftp.oreore.oredayo.tokyo/test/」へのリンクが張られます。
しかし実際には、下図でいえば、「FTPログインID」フィールドや「ルートパス」フィールドの内容を合成することができれば、より実用的でしょう。
まあ、この例にかぎっていえば、「FTP URL」というフィールドを作れよ、といわれればそれまでなんですが。
このほかに、カスタムフィールドのデータ型として「リンク」も新設されております。
URLそのものがフィールド内容となる場合にはこちらがお手軽です
IT技術者の生き残る道はIT業者でなくユーザー事業部内にしかない
IT部門が没落すればIT業界の大概の問題は片付く
という記事を読みました。
という三段論法なのですが、1と2は同意です。
すでにそのような動きを、一般の報道に現れるさまざまなニュースでも、ひしひしと見て取ることができます。
しかしこの木村氏も強く警鐘を鳴らしているように、実は2から3へはオートマティックな帰結ではない。
IT部門から仕事が出なくなったからといって、当然、事業部門が自動的に既存IT業者へ仕事を出してくれるようになるわけではないのだ。
それどころか、木村氏が前提にしているのとは異なり、私は、事業部門はそもそもIT業界へ仕事を外注しないケースが増えていくのではないかとみている。
理由は、木村氏の文章でも指摘されているように、事業部門が進めるIT案件は本質的にアジャイル性・小規模性を有するからである。
事業部門のITプロジェクトの試行錯誤とは、事業の試行錯誤そのものである。
なぜなら事業部門のITとは事業そのものだからだ。
アジャイルなやりとりを外部と行うほど効率の悪いことはないだろう。
外部業者が提案できる程度のイノベーションなら、そのユーザー企業のどこのライバル企業も当然に取り入れていくと思われ、新たなコアコンピタンスになどとてもなりえないのではないかとおもわれる。（そもそもそれで満足してたら事業部門の存在意義がない。）
よって問題は、IT業者はいかにこの先生き残るか？
ではない。
IT業者は現在のような形では生き残れないこと前提で、IT技術者がいかに生き残るか？
が、いま現在IT技術者として生計を立てているひとにとっての重大なテーマだろうとおもう。
これからITやプログラミングを学ぶひとについては、IT技術者などにならず、プログラミングを専業で行うなどという酔狂な道へ進まず、事業側へ入り込み、あるいは事業を立ち上げ、みずからプログラミングを行うのがもっともストレートフォワードな道であることは、火を見るより明らかな論理的帰結であることはいうまでもない。
という記事を読みました。
- 事業部門がバリバリITを活用して新事業展開や業績浮揚を図るようになるだろう。
- それについていけない頭の堅いIT部門は没落し、結果として、IT部門を頂点とするIT業界ピラミッド構造は崩壊するだろう。
- そのピラミッド構造に伴っていたIT業界の諸問題も解決するだろう。
という三段論法なのですが、1と2は同意です。
すでにそのような動きを、一般の報道に現れるさまざまなニュースでも、ひしひしと見て取ることができます。
しかしこの木村氏も強く警鐘を鳴らしているように、実は2から3へはオートマティックな帰結ではない。
IT部門から仕事が出なくなったからといって、当然、事業部門が自動的に既存IT業者へ仕事を出してくれるようになるわけではないのだ。
それどころか、木村氏が前提にしているのとは異なり、私は、事業部門はそもそもIT業界へ仕事を外注しないケースが増えていくのではないかとみている。
理由は、木村氏の文章でも指摘されているように、事業部門が進めるIT案件は本質的にアジャイル性・小規模性を有するからである。
事業部門のITプロジェクトの試行錯誤とは、事業の試行錯誤そのものである。
なぜなら事業部門のITとは事業そのものだからだ。
アジャイルなやりとりを外部と行うほど効率の悪いことはないだろう。
外部業者が提案できる程度のイノベーションなら、そのユーザー企業のどこのライバル企業も当然に取り入れていくと思われ、新たなコアコンピタンスになどとてもなりえないのではないかとおもわれる。（そもそもそれで満足してたら事業部門の存在意義がない。）
よって問題は、IT業者はいかにこの先生き残るか？
ではない。
IT業者は現在のような形では生き残れないこと前提で、IT技術者がいかに生き残るか？
が、いま現在IT技術者として生計を立てているひとにとっての重大なテーマだろうとおもう。
これからITやプログラミングを学ぶひとについては、IT技術者などにならず、プログラミングを専業で行うなどという酔狂な道へ進まず、事業側へ入り込み、あるいは事業を立ち上げ、みずからプログラミングを行うのがもっともストレートフォワードな道であることは、火を見るより明らかな論理的帰結であることはいうまでもない。
巷の記事の「Redmineこんなことができない」がすでにほぼ標準実装済みな件
bitnamiのRedmineスタックをWindowsにインストールしました。
まずはDTPの、しっちゃかめっちゃかになりがちな、進捗管理に便利に使う予定です。これについてはほとんど標準機能で。
ちなみに巷のあちこちのページに「Redmineってどうしてこんな簡単なことができないの？」という記事があるので、そのへんは運用でなんとかすんべとおもっていましたが…。
ほとんど、できるように標準実装済みとなっていました。
あとは、納期に時刻まで設定したいので、そのカスタムフィールドを追加したときに、チケットの画面で納期の日付の隣に表示されてほしいということがあるのだけど、これはたぶんテーマとかでできるのだろうな。（追記：テーマはCSSカスタマイズと若干のJS追加をできるだけだそうです）
さらに研究研究…。
ゆくゆくは、刻一刻流れる切り抜きとかの粒度の細かい作業の生産管理のプラットフォームとしても使いたい考えです。RailsでRESTfulな何かを書いて、あとたぶんLimeChatのスクリプトを書きます。これについては過去のいくつかの記事で研究過程を掲載してあります。
経営とはシステム構築なり。
まずはDTPの、しっちゃかめっちゃかになりがちな、進捗管理に便利に使う予定です。これについてはほとんど標準機能で。
ちなみに巷のあちこちのページに「Redmineってどうしてこんな簡単なことができないの？」という記事があるので、そのへんは運用でなんとかすんべとおもっていましたが…。
ほとんど、できるように標準実装済みとなっていました。
あとは、納期に時刻まで設定したいので、そのカスタムフィールドを追加したときに、チケットの画面で納期の日付の隣に表示されてほしいということがあるのだけど、これはたぶんテーマとかでできるのだろうな。（追記：テーマはCSSカスタマイズと若干のJS追加をできるだけだそうです）
さらに研究研究…。
ゆくゆくは、刻一刻流れる切り抜きとかの粒度の細かい作業の生産管理のプラットフォームとしても使いたい考えです。RailsでRESTfulな何かを書いて、あとたぶんLimeChatのスクリプトを書きます。これについては過去のいくつかの記事で研究過程を掲載してあります。
経営とはシステム構築なり。
2014年8月6日水曜日
男の硬派ライフハックシリーズ「二個は一個なり、一個は無しなり。バックアップは臆病者の徴に非ず、勇気の源なり」
なにかと軍隊やアウトドアでのエピソードやたとえが飛び出す芸風の一貫性が心地よい男の硬派なライフハックサイトThe Art of Manlinessから本日の教訓です。
何かを二個備えてあるなら、うち一個は想定外で壊れて一個になると想定せよ。
何かを一個しか備えてないなら、それは想定外で壊れて装備ゼロになると想定せよ。
これは計画の代替案についても同様と考えよ。
バックアップがあってこそ、男は大胆に任務に邁進することが可能となると肝に銘じよ。
バックアップは臆病者のしるしではなく、むしろ想定外を成長につなげる真の男の態度と知れ。
2014年8月4日月曜日
専業プログラマーが楽しいわけがない
プログラムを書くひとが報われやすい時代が近づいているという意見を多く聞くようになりました。
しかしそれは、専業プログラマーが報われるという意味ではないとおもいます。
たとえば社長をやりながら、自分の会社のためのプログラムを書く。
たとえば農場主をやりながら、自分の農場のためのプログラムを書く。
そのように、自分の専門があって、その専門のために兼業でプログラミングをする専門家が、プログラミングをしない専門家よりも、報われやすい、という時代が来るということだとおもいます。
もちろんPHPゴリゴリとかではなく、Railsみたいなフレームワークに依拠して書くことが多いだろうとおもいます。
そういうフレームワークが整った現代は、兼業プログラマーが育ちやすい環境が整備されているとおもいます。
プログラミングが楽しいと思えないのは悪いことなのか
という記事を読みました。
これは、他人に売るプログラムを書くことを仕事とするひとの話ですね。
かつ、それだけを仕事とするひとの話だとおもいます。
というくだりからも、その前提が察せられます。
というくだりは、広義に解釈すれば、自分のために書いたプログラムによって業務が改善され、それによって顧客やユーザーに価値を提供するともとれます。しかし
というくだりから察するに、やはり筆者の念頭にあるのは、他人のためにプログラムを書くひとだろうとおもいます。
他人のためのプログラムを書くことは、もちろんプログラミング自体を好きなひとにとっては、それでも楽しいことだろうとおもいます。
しかし所詮は、他人のための物ですので、それを楽しむことができないひとも一定数いるのは、当然のことだとおもいます。
それに対して、自分の仕事の改善のためにプログラミングを行うことは、楽しくないわけがないとおもいます。
その意味で、プログラミングが楽しくないひとにならないためには、自分の専門にいかにプログラミングを活かせるかを考えることが重要だとおもいます。
とくに経営者は、自分の会社の改善のために、みずからコードを書くことができれば、それをできない経営者よりもだんぜん有利になることは間違いありません。
他人にプログラムの仕様を伝える必要がないし、プログラミングで何ができてなにができないかをはじめから本人がわかっているからです。
しかしそれは、専業プログラマーが報われるという意味ではないとおもいます。
たとえば社長をやりながら、自分の会社のためのプログラムを書く。
たとえば農場主をやりながら、自分の農場のためのプログラムを書く。
そのように、自分の専門があって、その専門のために兼業でプログラミングをする専門家が、プログラミングをしない専門家よりも、報われやすい、という時代が来るということだとおもいます。
もちろんPHPゴリゴリとかではなく、Railsみたいなフレームワークに依拠して書くことが多いだろうとおもいます。
そういうフレームワークが整った現代は、兼業プログラマーが育ちやすい環境が整備されているとおもいます。
プログラミングが楽しいと思えないのは悪いことなのか
という記事を読みました。
これは、他人に売るプログラムを書くことを仕事とするひとの話ですね。
かつ、それだけを仕事とするひとの話だとおもいます。
こうした取材から見えてきたのは、優れたプログラマの間では「プログラミング技術一本で生きていくには、前提としてプログラミングが好きである必要がある」と固く信じられているということです。
というくだりからも、その前提が察せられます。
当たり前のことですが、仕事としてプログラミングをする目的は、顧客やユーザーに価値を提供することであって、自分が楽しむことではありません。
というくだりは、広義に解釈すれば、自分のために書いたプログラムによって業務が改善され、それによって顧客やユーザーに価値を提供するともとれます。しかし
逆に、顧客やユーザーを無視して、好みの開発環境や自身の心地よさばかりを追求するプログラマは、プロとは呼べないでしょう。
というくだりから察するに、やはり筆者の念頭にあるのは、他人のためにプログラムを書くひとだろうとおもいます。
他人のためのプログラムを書くことは、もちろんプログラミング自体を好きなひとにとっては、それでも楽しいことだろうとおもいます。
しかし所詮は、他人のための物ですので、それを楽しむことができないひとも一定数いるのは、当然のことだとおもいます。
それに対して、自分の仕事の改善のためにプログラミングを行うことは、楽しくないわけがないとおもいます。
その意味で、プログラミングが楽しくないひとにならないためには、自分の専門にいかにプログラミングを活かせるかを考えることが重要だとおもいます。
とくに経営者は、自分の会社の改善のために、みずからコードを書くことができれば、それをできない経営者よりもだんぜん有利になることは間違いありません。
他人にプログラムの仕様を伝える必要がないし、プログラミングで何ができてなにができないかをはじめから本人がわかっているからです。
登録:
投稿 (Atom)