リモートワークはとても難しいという話をしてきました - だいくしー(@daiksy)のはてなブログ
"Agile Japan 2017 京都サテライト", "KANJAVA PARTY 2017" で、『リモートチームの道具箱』というタイトルのセッションでお話をさせていただきました。 connpass.com kanjava.connpass.com リモートワークに取り組んでいるチームで仕事をして3年目になりますが、リモートワークは難しいなーというのを常々思っています。 世の中はどちらかというと、リモートワークという素晴らしい取り組みをどんどん推進しようという流れに向いています。リモートワークの推進には僕も賛同するのですが、一方で、「難しさ」の部分があまりクローズアップされません。このまま、導入だけが先行してしまうと、結局「やっぱりリモートワークなんて止めたほうがいいのでは」となってしまう恐れがあって、それを懸念しています。 リモートワークは上手に使いこなせば、柔軟な働き方が促進される
アリスとボブはパスワードつきzipをメールに添付したりしない - 暗号技術入門を読んだ - - だいくしー(@daiksy)のはてなブログ
パスワードつきzipの添付メールと鍵配送問題 ボブのもとに届けられたアリスからのメール。このメールにはzipファイルが添付されていて解凍にパスワードが必要だ。このパスワードは、添付ファイルの後、アリスから別のメールに記載されて送られてくる。この手順により、最初のメールをイブが盗聴したとしても、イブはパスワードを知らないので添付ファイルを解凍することはできない。 一見すると安全に情報をやりとりしているようにみえるこの形式は、実はまったく安全ではない。ファイルが添付されている最初のメールが盗聴できるのであれば、当然イブは次に送られるパスワードが記載されたメールも盗聴できるからだ。 zipに施されるパスワードの強度はとりあえず気にしないこととして、この情報のやりとりは暗号におけるとても重要な問題をないがしろにしている。それは鍵配送問題と呼ばれる。 暗号の中には、かなり早い段階で「絶対に解読不可能
Scala関西Summit 2015の裏側！ - 大規模カンファレンスの作り方 - - だいくしー(@daiksy)のはてなブログ
Scala関西Summit 2015 でスタッフをやっていた。 おかげさまで大盛況で、とてもよいイベントだった。 せっかくこういう大きなイベントの最初期からスタッフとして関われたので、経緯などを書いておこうと思う。 summit.scala-kansai.org 何をやったの? 勉強会当日はメインホールの司会とパネルトークの登壇など。 準備段階ではなんかいろいろやってた。 経緯 去年のScalaMatsuri2014の会場で、今回のSummitの実行委員長となる@aa7thさんと「関西でも大きなScalaイベントやりたいね」という話などをしていた。 その後、Facebookメッセンジャーの記録によると、2014年の10月23日に@aa7thさんから「そろそろ準備を始めましょう」と何人かのメンバーに呼びかけがあり、そのときに声をかけてもらう。ここから考えると9ヶ月かかったことになるのか。。。
勉強会の無断欠席は永久になくならないから僕らが工夫しよう - だいくしー(@daiksy)のはてなブログ
photo by E R I mollifier.hatenablog.com ITコミュニティ界隈で定期的に話題になるこの問題。 定期的に出る、ということは、無断欠席は永遠になくならないと思ってよさそうだ。 そもそも他人の行動を制御するのは不可能なので、制御可能な自分たちの運営を工夫して解決し、関係者全員が幸せになれる方法を考えよう。 有料とかブラックリストとかほんとに有効？ この話題でいつも意見として出るのが、前金制キャンセル不可の有料制にしてはどうか、とか、無断欠席者のリストを共有する、とかいった話。 ただ、ブラックリスト作ってもリストに載ってない無断キャンセルなんて無限に存在し続ける。 有料制も、会場によっては営利目的とみなされて使用料がそれによって跳ね上がったりする。 そもそも、無断キャンセルによって補欠登録になってしまっていた人の参加の機会が奪われるのを何とかしたい、というのが
「駅すぱあと」を支える技術とDSLの話 - だいくしー(@daiksy)のはてなブログ
「駅すぱあと」を支える開発 〜９２６２の可能性を繋げ！〜(DevLOVE関西Ver) というイベントが開催された。 ぼくも会場係としてスタッフ参加。 「駅すぱあと」の歴史から技術、開発のマネジメント手法に至るまで、幅広い話が聞ける良いイベントだった。 いろいろな話が聞けたのだけれど、僕は特に佐藤さんの「『駅すぱあと』新しい開発基盤の研究」がおもしろかった。 まだ開発途中で、実際の駅すぱあとには組み込まれていないそうなのだけれど、佐藤さんは「駅すぱあと」の運賃計算のDSLを研究・開発しているという。 曰く、鉄道の運賃計算は泥沼である。単純に距離や、目的地までの駅数などで運賃が算出できればよいが、鉄道の運賃計算には無数の特例がある。 下記リンク先に、JRの運賃の特例計算が列挙されているので、ちょっと見ていただきたい。 ……お分かりいただけただろうか。現在の「駅すぱあと」では、これらの特例がすべ
IT勉強会カレンダーの思い出 - だいくしー(@daiksy)のはてなブログ
IT勉強会カレンダーの定期更新が終わるらしい。 ふと振り返ると、このIT勉強会カレンダーという存在が自分の人生にとって大きな影響を与えてくれていたことに気づいた。その思い出を書いておこう。 数年前、とあるエンジニア向けサイトで読者コラムニスト募集というものがあった。思うところがあってそれに応募したところ、採用され、そこから何本かのコラムをそのサイトに投稿する。 ある時、そのサイトに投稿している読者コラムニストのオフ会がある、というので行ってみた。メンバーの何人かとはそれまでにTwitterなどで交流があり、実に楽しいオフ会だったし、そこで僕は人生初のライトニングトークにチャレンジしたりもした。 そのオフ会で、IT系のコミュニティの存在を知る。ITの様々なトピックごとに、各地で勉強会やイベントが開催され、そこでエンジニアたちの交流があるのだという。 人生初のライトニングトークがそこそこウケた
ソフトウェアエンジニアの越境 - エンジニアも営業を学べ！？ - - だいくしー(@daiksy)のはてなブログ
DevLOVEアドベントカレンダー 越境 12日目の記事です。 今年のテーマは越境。ということで、ソフトウェアエンジニアの現場における「越境」について考えてみようかと思います。 いまいち納得のいかない片方向な越境 「エンジニアも営業的な目線を持ってセールスに貢献すべきだ！」 「エンジニアも自ら企画を立案し、サービスの売上げアップに貢献すべきだ！」 多くのエンジニアが、このような物言いを苦々しい気分で聞いた経験があるのではないでしょうか。 営業職の偉い人は、エンジニアもセールスを学び、営業の視点を持て、と言う。 企画職の偉い人は、エンジニアも企画を学び、サービスを立案しろ、と言う。 ところがエンジニアリングを学ぶ営業や企画の人は少ないし、エンジニアリングを学ばない営業職や企画職が、それを理由に咎められている様子など一度も目にしたことはありません。 なぜエンジニアばかりが開発以外のスキルまで求
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
