2015 7月16日 23:14
すごい広島113で遊んでたこと。 テスト環境を提供しないといけなくて、Dockerつかいたかったけど、今回はVagrantのBoxでベースを提供することにした。 Packerつかうと時間がかかるのでvagrant packageでつくって、Vagrant Cloudにおいたりしてました。 ちょっと久しぶりにPackerでboxをつくるかーってAtlasにいってみたら、Web上に表示されたチュートリアルにそってコマンドラインで作業するだけでBoxがつくれるようになってました。 しかも、Packerの実行をAtlasがやってくれます。しかも、VirtualboxとVMwareのイメージ両方つくってくれます。 しかも、勝手にBoxesに登録されます。 素敵です。 Atlasにサインインする Build Vagrant Boxes with Packer and Atlasというメニューがあってクリックする packerのバージョンの確認をさせられる。0.8.0より最新かどうか。 PackeのTemplaterをもってるかきかれます。もってなかったら atlas-packer-vagrant-tutorialが使えると教えてくれます。 API TOKENが生成されるので、環境変数に登録します packer push をつかって template.jsonとscriptをAtlasに送信します 進行状況をAtlasで閲覧できます。だいたい30分ぐらいかかります。 そうすると、boxができて、Atlasから取得できるようになります。 ここから配布していると vagrant box update でboxが更新できたりとなかなか嬉しいです。 他に遊んだこと tutorialのものはUbuntu12.04だったので14.04にかえたりしました。 railsが実行できる環境つくって遊びました。 mysqlとrubyをいれてるだけです。2.1.6なのは大人の事情です。 公開するboxは一度公開したバージョンの場合、最終的なPackerの実行が失敗します。 成果物が登録できないからです。 メタデータを修正して、新しいバージョンに変えるようにしてください。 具体的にはこの辺を参考にしてください。versionを0.0.4にしています。 実際につくったVagarantのBoxはこちらにあります。 vagrant init eiel/rails-ymqsl とかすると使えます。 Vagrantのboxをつくるのに、Packerをつかうとローカルマシンが占有されてつらかったのですが、Atlas上でビルドできるようになってたいへん幸せです。 継続的デリバリー感がします。とても楽しいので一度遊んでみてください。
2014 12月3日 00:00
一応、ゆるい広島 Advent Calendar 2014の三日目の記事になります。 12月1日のお昼にIBM Cloud Exchange 2014の広島が開催されておりましたが、その夜にひっそりとすごい広島 x IBM - クラウド座談会が開催されました。 すごい広島という弱小コミュニティがIBMさまといったいどんな交流をしたらいいのかよくわかりませんが、ここは弱小なことは気にせず、対等な振りをして対等なつもりでいつもどおりすごい広島の紹介をしてきました。 なるべくゆるくいこうとはじめからおもっていたので、「すごい広島っていうのはー」という、すごいゆるいタイトルをつけてみました。 まとめると、すごい広島は、すごい人を集めるのが目的のようです。 すごい広島の話はもう何度もしていますが、IBMの方たちを対象にしたとき、なにをしたいコミュニティなのか改めてブレストをして臨みました。 そうすると普段のすごい広島の参加者から、「そんな目的が!」なんて声が聞こえました。 なんとなく新しいスライドをつくった甲斐がありました。 あとあと、SoftLayerユーザ会 広島支部を作りたいそうです。 支部長希望者探しているようです。主に女性。 少し脱線しますが、今回挑戦したことは自分が撮影した写真を使うというところでした。 ちなみに、使用しているカメラはRICOH GRです。 たぶん高級コンパクトデジタルカメラに分類されるカメラで、起動がはやく気軽に撮影できて、ミラーレスと同等のセンサーサイズを備えるなかなか素敵なカメラです。 このカメラの素晴しいのはレンズ沼にはまらないということがあります。 低価格帯のミラーレスの少し触らせてもらっいましたが、良いカメラを買ったと感じております。 でも、フルサイズの一眼レフ欲しくなるので、沼には確実に近づいていますね。 閑話休題。 コミュニティを運営することに関しては、わりと無欲におこなって継続できるペースで続けるのがいいかなとなんとく改めて思いました。 継続することから産まれるリターンが計ることができないように思います。 「だからこそ、企業との対話、連携に価値が産まれるのかな」なんて思いました。 お互いにとって価値のあることがもっとできるようになるといいですね。
2014 9月21日 10:50
すごい広島を紹介するための書籍(通称、薄い本)である、すごいHiroshimaの本というものを作成しました。 作成した主の目的はオープンソースカンファレンスで展示をするためです。 作成した電子書籍はすごいHiroshimaの本置場というところに置いています。 ePubとPDFを提供しています。 OSC2014広島編 せっかく電子書籍を作ったので、興味をもってもらうために、オープンソースカンファレンス2014広島のLT駆動開発 ベストセッションズ – 凪のライトニングトークの中でライトニングトークをしました。 題して、すごいHirohsimaの本のここがヒドいです。 少し、補足。 しつこいですが、我馬は広島のラーメン屋です。博多ラーメンを提供します。 私とすごい広島の章は実際には4人しか書いていません。 一人で5役している人がいます。誰やねん。あ、でも一役は入れ替わる可能性も。 第71回 WEB TOUCH MEETING OSC2014広島と同日に行なわれたWEB TOUCH MEETING 71で、Web製作者向けにこの書籍をつくるのに利用技術がどんなものなのか、すごい速さでざっくりと紹介しました。 対象者をWebの初心者にすればよかったと少し反省しております。 速さ自体はやや意図的にやった部分はあるのですが、いろんな参加者がいて真ん中あたりの人を対象にしてしまった感じがあります。 よくわからないけど、キーワードをひろってもらったりしてもらえた良いかなぁ。という感じでつくりました。 それよりも図はもっとがんばらなければ。 スライドは前半のすごいHiroshimaの本のここがヒドいの部分はカットしてアップロードしています。 そして補足。 電子書籍をつくるためにはRe:VIEWを利用しました。はじめて挑戦する場合はクイックスタートガイドを読めば良いと思います。 Re:VIEWは電子書籍をつくりたい場合でも、技術書を書きたい人向けのものっぽいです。プログラミングなどをしてない人には少し扱うのが難しいかもしれません。 ただ、環境さえ用意できれば、使うこと自体はは難しくはないと思います。 書くだけとかなら。 本の中でグラフをかくのに今回gnuplotを利用しました。 gnuplotは理系の学生であれば利用したことが多いと思われるグラフ作成ツールです。コマンドラインから利用します。 Re:VIEWではgnuplotのコマンドを書く方法が用意されていて、PDFに変換する時はPDF用の画像をつくってくれて、ePubに変換する時はePub用に画像をつくってくれます。 ありがたい。 この本をつくるにあたって、最初にしたことは、ePubとPDFに変換する部分を自動化したことです。 もし途中で執筆に誰かが参加しようと思った時に作成されるものをわかりやすくしたり、本が生成されてるところを見せて、興味をもってもらおうと思ったというのが主な目的です。 他にも執筆に集中してしまって、いざePubやPDFに変換する際にトラブルで間に合わないという自体を避けるなどの理由もあります。 実際に文字化けとかグラフが生成されなかったり、予期していなかったエラーを事前に発見することができました。 Octokitは付録の「すごい広島の統計情報」「すごい広島の参加者」を作成するために、利用しています。すごい広島のサイトの情報がおいてあるGitHubのリポジトリgreat-h.github.ioから情報を取得して、gnuplot用のCSVを作成したり、Re:VIEWの.reファイル内に挿入する文字列を作成しています。 Octokitを使った例として、GitHub戦闘力があります。(GitHub戦闘力が完全にこれを作るときの副産物である) 蛇足ですが、この電子書籍には他にも最新の情報を取得して、更新している部分がいくつかあります。 コミットの数なんかは随時変化していくので、ePubやPDFを作成する際に最新情報を使うようにしています。 対象読者に対して説明不足になってしまうのですが、この電子書籍はgit pushしたら自動生成するようにしています。 これを実現しているのがCIサーバで今回利用したサービスがWercerです。 CIサーバでできることは結局は自分のコンピュータできることと基本的に同じです。 しかし、CIサーバを使うと基本的にクリーンな状態でePubやPDFを作成することができます。 これがどんな時に嬉しいかというと、執筆者が増えた時に、ePubやPDFをつくるのに、自分が追加し忘れたファイルがないことを保証できます。 (一部のファイルがキャッシュされたりはじますが…) また、ePubやPDFを生成するための手順をコードに落とす必要がでるため、作成方法が明確なります。 こういったことを早めにやっておくと、本を作成するための全体像を把握しやすくなります。 Werckerを使う際にRe:VIEWを使うための仮想マシン(box)も作成しました。 この詳しい話は今回割愛しますが、リポジトリは晒しておきます。 eiel/wercker-box-review Werckerで作成したePubやPDFはAmazon S3へアップロードしています。 作成したファイルはtmp/great-h-book-[バージョン番号]というファイル名にして保存しています。 これらのファイルは1週間たつと削除されるようにしています。こちらはAmazon S3の機能です。 ただ、masterブランチものをCIサーバに動かした場合は、great-h-bookというファイル名にして、消えないようにしてあります。 (厳密にはファイル名はオブジェクト名ですが…) Amazon S3はとても安価で信頼性も高いので、最近、成果物はなるべくS3におくようにしています。特に変更がもうないものを置くのが良いと思います。 最後に、ePubやPDFが生成されたことがみんなに伝わらないと意味がないので、Twitterに流すようにしています。この時にユニークなハッシュタグをつけるようにしています。 夜フクロウは特定のキーワードを含むツイートを音声つきで通知する機能があるので、これも使ってます。 とても便利です。 継続的デリバリなんて言葉を使いましたが、みんなで一緒になって何かをつくるときはみんが嬉しくなるようにやるのが大切だと思います。 書く人も、確認する人も、作りたい人も、読む人もみんなチームだよね。
2014 7月28日 17:39
ひろしま発人材集積促進プロジェクトというのが行われていて、通称「ヒロハタ」というらしいのですが、その第1回 レギュラー・ミーティングがあったのですごい広島 をネタに潜入してきました。 「ヒロハタ」というのは一言からいうと、広島にクリエイティブな人材を集めようというプロジェクトだと思われます。 第１回のミーティングはプロジェクトに応募したアイディアのプレゼンテーションをするというもので一部のプレゼンが Ustream で配信されていました。 もうすでに動いているプロジェクトでさらなるブラッシュアップを計る人たちや、準備中で動いてはいるけど表に出るようなアウトプットはない人たちだったり、構想だけのものだったり、いろんな立場の人たちがいました。 参加してみると、こういった人たちがつながり相互に良い影響を与えようというのがプロジェクトの目的のように感じました。 「すごい広島」の立ち位置自体は協力できそうなプロジェクトをみつけて、Webアプリケーションのプロトタイプを作成してみたり、良いと感じたものを広めるお手伝いをしようという目論みです。 「すごい広島」は結果的にすごいエンジニアをみつけることができればメリットになります。または、作成したプロトタイプのつづきの作成するエンジニアをみつけることができればメリットになるかなぁ、というそんな感じです。 個人的には、参加者同士が交流する方法が少ないので、他の参加者の現状を見える化やコミュニケーションをとる何かがあるといいなぁ、と思っているところです。 関連 ヒロハタ～Web・ITを活用してアイデアの事業化を目指そう～
2014 7月7日 17:14
LT駆動開発 05 でライトニングトークをした。 6月はすごい広島のBOTを作って遊ぶことをしていた気がしたのでこれを紹介することにした。これは Ruboty で作成した。 何か毎回やってないネタを挟みたいということで、ふたつスライドを用意して相互参照するというネタをした。 まずは、BOTの具体例である「すごい広島 BOT」を紹介することでなにがしたいのかをBOTを知らない人に理解してもらう。 そこから、どうやってそれを作るのか。というところに焦点をおいたというライトニングトークするという流れである。 しかし、実際、ふたつもライトニングトークをする時間があるかどうかわからないので「Rubotyの使い方」はかなり適当につくってしまった。 類似性を持たせるために、前半は同じ構成になっている。 最終的にしたいことは、「すごい広島のTwitterアカウントを誰か運用してくれ」ということかもしれない。 すごい広島のBOTは今後もプロキシーBOTとして活躍していただきたいところである。 ruboty-twitter の fork をみてみると、デバッグ用のコード仕込んでみたりとかしているところがあって、うまくメンションが返ってこなかったからかと思い、その辺を補足してみたという経緯があったりなかったりもします。 関連 Rackup で Ruboty すごい広島 一周年 LT駆動開発という勉強会をはじめるよ
2014 5月23日 10:51
すごい広島って勉強会というかミートアップが一年間、毎週休まず活動したらしい。「すごい」というか、めでたい。 概要 すごい広島とは何か 一年間活動してみて すごい広島とは何か すごい広島は、「ITエンジニアとか、情報系の学生とか、Web系デザイナが毎週どこかに集まっていればそれだけで面白いことになるはずだ」 と考えた @Toro_kun と @CentBoss と @eielh がはじめたミートアップらしいです。(他人事) 「すごい広島」は、もともとすごいHaskell を楽しく学ぼう という書籍の読書会を広島でやろうとした際に考えた名前だそうです。 しかし、Haskell の需要が少ない関係で、参加者が見込めないため、読書会はお蔵入りしてしまいました。 せっかく考えた名前は面白いし、どこかで使いたい。 そこで、流用したのが「すごい広島」となりました。 しかし、ただ集まるだけでは目的を見失う恐れがあります。 「広島のエンジニア」のアウトプットの総量を増やすことによって広島が盛り上ってるように錯覚させることができないか考えることにしました。 結果、参加ルールを設けることにしました。 その場で何をするつもりなのか GitHub の Issue に書く すごい広島内でブログを書く GitHub に Pull Request をする というルールです。 GitHubに慣れてもらうために、開発でない部分にGitHubをつかおうとする試みです。 最初に Pull Request した時の楽しさを伝えたいというのもありますし、GitHubを使える人と仕事をしたいという裏の目的です。 結果、GitHubを練習するための場として定着するようになりました。 しかし、ブログをかくのは少し負担が大きいということになり最近では「何かしらのやったことをウェブに残すこと」というルールに緩和されました。 ところで、広島でもIT勉強会は土日にそこそこの数あります。 自分がいろんなすごい人たちの話を聞きたいのもありますが、土日以外なら参加できる人もいるかもしれない。 毎週やっていれば、月に1回ぐらいは来られるかもしれない。 そんな気持ちでやっています。 気がつけば、すごい広島はほぼ毎週参加されている人は3,4人います。 いつもいる人を中心に、輪が広がり、相乗効果が起きるといいと思っています。 一年間活動してみて つづけたいこと 毎週活動する 学生など若い人を優遇する 学生が来る場合は、社会人がひとりいるだけでも学生にとっては参考になる話も聞けると思うので、それだけでやってる価値がでて良いと思います。 問題点とか直したい点 人数が多いと喫茶店だと迷惑がかかる 参加者の固定化 名前からやってることが想像をしづらい。なにしてるか不明。 よく参加する人はステップアップして欲しいが、その道を示してない。 はじめての参加者に優しく、参加しやいように メンバーの固定化はちょっと深刻な気もします。 なるべくはじめてきた人が入りにくくならないように気をつけたい。 挑戦したいこと みんなが勝手に準備して、勝手にまわるように 協賛。活動することにメリットがある企業をみつけて支援してもらいたい。 企業に協力してもらいたいところはちょっとある。 その他感じてること 大人がんばれ 参加者に学生がわりと多く、どうやら大学の同好会の活動の一部になってきているらしいです。 それこそ学生が参加して価値を提供できるように社会人ががんばるようになるとすてきだと思います。 2ヶ月に一度ぐらい来る人とかが数人いるとちょっと雰囲気が変わるかなとも思います。
2014 2月19日 18:43
すごい広島 #40 で書いてる。 すごい広島には GitHub に馴れるというサブの目的が存在します。 参加者は 「GitHub にプルリクエストをしなければならない」というルールがあって、参加するだけでプルリクエストの練習することができます。 プルリクエストを体験することで、GitHubがどういうものなのか理解してもらおうという魂胆です。 どんなプルリクエストを行うかというと、すごい広島のサイトに情報を追加してもらいます。 すごい広島で何をしているのか GitHubのIssue に書いてもらっているので、そこへのリンクを貼るのが一番簡単な変更となります。 さて本題です。 40回を迎えたことだし、もっと実際の GitHub の作業フローに合わせるためにすごい広島のプロセスの中に CI サーバを登場させることを考えてみました。 すごい広島のサイトは GitHub に生成させていましたが、Travis-CI でサイトを生成するようにしました。 プルリクエストすると Travis-CI でサイトが生成できるかどうか確認します。 これで、プルリクエストを本流にマージする際にサイトが生成できることを確認してからマージすることができるようになりました。 これで少しだけですが、より実際の開発の流れに近づけることができたはずです。たぶん。 下図はTravi-CI でサイトが生成できるかどうか確認中の時のプルリクエストのマージボタンです。 ついでに静的サイトジェネレータを変更する せっかくなので、静的サイトジェネレータもJekyllから別ものに変えることにしました。 GitHub 上でビルドしなくなるので Jekyll でもいろいろできるようになりますが、どうせ機能面で優れたものに変えたいですよね。 候補は middleman か sitespec だったのですが、sitespec を試してみたかったので sitespec にしてみました。 Sitespec sitespec は rspecをつかってサイトを生成します。 Sitespec を使ってみて良い点は、普段のテスト駆動開発っぽいプロセスで開発できて、思考を変えなくてよかったところです。 作成したいページの spec を書いて、 rspec を実行するとそのページが生成できないことが確認できます。 そこからは好きな方法で Rack アプリケーションを用意してあげればよいのです。 あとは通常のウェブ開発と同じやり方になりそうだと、sitespec を使いはじめてすぐにわかりました。 Rails や Sinatra に馴れているのであればそれを使えばよくて、拡張機能もそれぞれのフレームワークのものが使えるし、足りないものがあれば同じ要領で開発すればよさそうです。 新しいことを覚えなくていいし、かゆいところに手が届きます。 また、なにか拡張機能を作れば普段の開発にも生かせそうなのも良いです。 sitespec は柔軟性がありますが、その代わりにやることがちょっと増えたりします。 気軽に作りたい場合は
2013 11月21日 12:11
すごい広島での出来事である。 いつかなる気がしていた。 GitHub からの通知のメールが迷惑メールとして判定された。 多数のユーザが同様のメッセージを迷惑メールとして報告しています。 迷惑ならそもそも通知が来ないようにするか、単に自動でアーカイブするようにして欲しいですね。迷惑メール報告すること自体が迷惑になります。 私が知る限りの通知の設定方法を紹介しておきます。 GitHub は常に進化しているので、動作や画面はいずれ変わってしまうかもしれません。 そもそもの通知設定 「GitHub からメールに通知して欲しくないよ!」という人は基本的な設定を見直しましょう。 Noticification Centerにアクセスをします。 設定 > Notification Center でアクセスすることができます。 自分が参加しているグループがだだ漏れですが、特に隠しません。 How you receive notifications に注目してください。 「通知をどのように受信するか」を設定します。 Participating Watching の二種類があります。 Participating のほうは @自分のGitHub ID が付いているような「自分が参加しているところに変化があった時」にどこに通知するかを設定できます。 Watching のほうは GitHub にリポジトリを watchする機能があり、「watch してるものに変化があった時」にどこに通知するかを設定できます。 Email のチェックを外せばメールは届かなくなるでしょう。そうではなくて、一部のリポジトリが活発すぎてついていけない場合もあります。 そのリポジトリを unwatch することで調整できます。これについては後述します。 Email という項目の他にも Web という項目があります。Web での通知は画面左上にあります。 クリックすれば通知内容を確認できます。 リポジトリのウォッチ リポジトリが活発すぎて、そのリポジトリの通知はちょっと見てる余裕がない場合はリポジトリを unwatch しましょう。 あるチームにいつの間にか入れらたしまった場合、自動的に watch されてしますので、こういうことがあります。 これは watch している状態です。 外す場合は、Unwatch を選択して Not watching を選びます。 自分のGitHub IDが登場しない限りは通知がこなくなります。 自分が呼ばれていれば通知がきます。 Not
2013 10月21日 16:44
すごい広島 も20回を越えて、そろそろ半年経とうとしています。 すごいですね。 #知らんけど そんなわけでコミュニティのとして GitHub を使ってみた感想を自分の中でまとめてみようと思います。 簡単に「すごい広島」について書いておくと、毎週やっている勉強会もどきでミートアップです。ITエンジニアが集まって雑談してたり作業していたりします。 思ってたより人が集まってる みんな GitHub になれてきた? マージされない Pull Request もっと Issue が作成されてもいいんじゃないか 思ってたより人が集まってる 自分が想像していたよりも人が集まっています。 みなさんありがとうございます。 どうせ「すぐ一人二人でもくもくーってなる」と、思ってたのですが、3人以下になったのは1回ぐらいしかないように思います。 参加条件は徐々に緩くしているのもあるかもしれません。 未参加の人からよくあった意見は、 行ってみたい ブログを書くのは無理 敷居が高そう 目的がよくわからない です。 「行ってみたい」の人は来れない場合の話がありますが、来れる人が言ってる場合はお世辞なんですかね。(煽り ブログを書くのは必須ではなくしたので、代わりに GitHub を思う存分試してみて欲しいです。 最近は Issue に作業をメモをとったりしています。 参考にしてください。 敷居が高くみえてしまうのは、変態扱いされない人のアウトプットが鍵になる気がしています。 期待したい。 「目的がよくわからない」の一番の理由は名称のせいかな。 やっぱり情報が読まれるかどうかはタイトル次第というのを改めて感じました。 それでも 「Web を見て参加しました!」が登場したので個人的には満足です。 目的のひとつが達成されました。 改めて「広島 勉強会」で Google で検索しましたが、ちょっと SEO 的にはまだまだです。その辺の工夫が必要そうでした。 みんな GitHub に馴れてきた? 参加者のほとんどが GitHub に馴れてない人です。 それだけ GitHub を使う環境がまだまだないのだと思います。 説明せずに Pull Request した人は僅かです。 そういう意味では効果があったと思います。 また、「非プログラマでも Pull Request はできているので難しくないよ」と言いたいのですが、なかなか良い方法がないです。(チラリ ちなみに、半分以上の人が
2013 10月6日 23:53
OSC 2013 HIROSHIMA に参加しました。 200名以上の参加があったらしいです。正確な情報が待ちどおしいです。 私も実行委員会に所属したり(あんまり手伝えてなくてごめんなさい)、Hiroshima.rb の枠でライトリングトークをしたり、すごい広島 と Hiroshima.rb の展示ブースで説明をしたりしました。あと、ライトニングトーク&じゃんけん大会 でライトニングトークをしてきました。前日の DB 勉強会 を含めると計3セッションをするという状況になりました。 Hiroshima.rb 広島でRubyが流行らないのはどう考えても俺たちが悪い Hiroshima.rbの発表については wiki に整理してあります。 というわけで、僕は毎年前座を務めているので、「Hiroshima.rb の紹介」と「広島でRubyが流行しているか調べた」のでその話をしました。 本当は僕も成果発表したかったのですが、時間が足りそうにないので諦めました。 その他のHiroshima.rb の活動は wiki にもまとめています。興味があれば覗いてみてください。 スライドは以下の感じなのですが、実際に使ったものとは違う完全版になっています。 広島で Ruby が流行らないのはどう考えても俺たちが悪い from Tomohiko Himura セッションを見にきてくれた方は20人以上いたと思うのですが数えてないのでわかりません。 セッションの元ネタは私がモテないのはどう考えてもお前らが悪い!でした。 セッションにはどこにもこのネタは入れてないので注意してください。 勝手にみんなのセッションをざっくり感想書いてしまいます。 岡山のRuby勉強会 岡山勢 まこぴー の LT です。 僕が「広島」と「岡山」の比較をしたので岡山の状況について喋ってくれました。 本人はもっとネタをいれればよかったといってましたが、もちろんいれるとよかったですが、岡山勢の牽制としては充分なトークだったと思います。 YouTube動画の再生回数がわし…気になります!! (きゅふぃーん うちの OSC でしか使えない秘密兵器 にょほう(にょ砲) の LT です。 4分超過の打ち切り御免のLTなら死んでいた。 息子さんの支援により笑いだけでなく、癒しも追加されたため、圧倒的に一番人気な LT になりました。 しかし、一番アニメ色があるセッションになっていた気がするのは言ってはいけない。 PaaSで簡単 Railsアプリを公開しよう！ ～もあぐれっしぶ～ ＆ Rubyを体験しよう！ 広島の基盤 たかた さんの LT です。 タイトル的にはもっともアニメ色の強いセッションですが、去年にひきつづきPaaSの紹介になりました。
2013 6月15日 19:39
WEB TOUCH MEETING #58 の LT 枠ですごい広島について LT をしました。 Githubの話はほとんどしていない。最近、隔週で何か喋ってる気がする。 主な目的は みんな広島を盛り上げようぜ です。 表面的には みんなもっとアウトプットしましょう 楽しいことをしよう というのをメインに話しました。 裏の目的は 自分のツイートだってコンテンツになりえるか です。 世の中には勉強会の存在を知らなくて一人でがんばってる人がいたり、 勉強会で何をやってるのかわからなかったり、 そういう人たちに地元の勉強会の存在を知る可能性を高くする。 あと LT できる人、したがる人を増やす。 LTやる人がいないと LTをやろうと思う人も増えない。 僕は人前で喋りたくない派なので、できるのはきっかけ作りをしたい。 そういう目的のセッションをしたつもりです。 すごい広島 from Tomohiko Himura というわけで、セッション補足。 up したスライドは削ったものを追懐しています。 Github ここを見ている人に書く必要はないと思いますが、オープンソースプロジェクトをしていく上で重要なWebサービスです。 言葉慣れをしてもらうということで解説は全くしませんでした。 気軽にアウトプット 気合いれてアウトプットするにはエネルギーが必要です。大作を毎週書くのは大変です。 「気軽に書きましょう」という話をしたかったですが、時間の都合上、削除しました。 LTも気軽にアウトプットできて、影響も大きいです。気軽に作れるように練習したほうが良いと思います。 なので、気軽にLTするには 広島Ruby勉強会を使うといいですよ。 という話をあらかじめ休憩時間の告知で伏線を貼ることで、省略しました。 アウトプットをすると勉強になる、かつ、そこに情報が集まる。 アウトプットをするにはそれなりのエネルギーが必要ですが、インプットするのはアウトプットに比べるとずっと少ないです。 気軽にコメントをしてくれたり、詳しい情報を聞こうと人が集まってきたり、強力なマサカリが飛んでくることで自分の理解を促進してくれます。 また、伝えようとすることで考えを整理することができます。 そういう話をざっくりしました。 また、ツイートも立派なコンテンツになるんじゃないかと、自分のツイートをスライドに使ってみたりもしました。 これは自爆気味なのでライフポイントがガンガン減ります。 県外のほうが楽しく見える 隣の芝生は本当に青いのか。 青くないのかもしれませんが、青く見えたら人はそちらに流れていく可能性があります。 そうです。潜在的に面白い人たちが都会へと流れてしまいます。 こういった勉強会に興味を持つ人が「地元には面白いものがないから」 と、都会へと行ってしまう。 特にいまから高い可能性を持つ学生が都会へ流れずに、地元へ残る選択肢を提示していきたい。 また、面白ければ「県外から広島は楽しそうだから」と、やってくる可能性もあります。 僕だって楽しいところに行きたいもの。 じゃあ、楽しくするしかないじゃないか。 楽しければいいの? ここは削った部分です。 「楽しいだけの勉強会は人は集まらないし、本格化しない。人が集まらないので継続は難しい」そんなマサカリを受けたことがあります。 ビジネスにならないとメリットを感じることが難しいので人がこないという話ですね。 実際、Ruby勉強会の参加者のほとんどがRuby初心者です。 でもね、エンジニアはビジネスをする人じゃない。
2013 6月12日 20:05
<htmlday> 2013でやったことプラスアルファ。 足りなかった部分はすごい広島 #4内で調査しました。 <htmlday> では AngularJS で遊びました 前にAngularJSを利用したときの復習 AngularJS を rails で使うのに使えそうな gemの調査 <html ng-app> と書けないの時の対処方法 AngularJS を rails で使うのに使えそうな gemの調査 とりあえず、Ruby Toolboxで angularを検索してみました。 候補としては angular-rails anglurajs-rails angular-gem angular-rails-engine と、乱立状態でした。他にもありましたけど、見る元気はありませんでした。 結論をまとめておくと 素の AngularJs でいいのなら angularjs-rails generatorなど、もしかすると便利になるものがあるかもしれないのが angular-gem という感じでした。 まずは、angular-rails を試しました。generator などついていますが、AngularJSの本体が更新されていない状態でした。 また、添付されている angle.js を読み込みすると動作しなかったりと問題もちらほらありました。 次にみたのは angularjs-rails です。これは Javascriptが添付されているだけのシンプルなものでした。添付されているものも最新で、unstable な最新バージョンも添付されていました。読み込みたいだけならこれで良さそうです。x unstableなバージョンをよみこむ場合は application.js に //= require_tree ./angular/unstable と、かけば良さそうです。 3番目に angular-gem です。前述の angularjs をフォークして複数のversion のAngularJSを取りこんでいたりと、なかなか意欲的です。 4つ目は angular-rails-engin です。angular_include_tag というヘルパーを提供してくれて、必要に応じて読込みして使う感じになるようです。 とりあえず、 angular-gem を試していこうかなと思います。
2013 5月23日 10:56
先週の土曜日にセキュリティもみじで 5分の LT をしました。 セキュリティの勉強会なのに、セキュリティと全く関係なかったり、5分を超過してたり、痛いツイート引用していたりと、恥ずかしい限りです。 しかも、ターゲットに設定していた広島の若い人が……参加してない! という、致命的な問題が発生しました。 仕方ないので、ネタにしておきました。 すごい Hiroshima で楽しく学ぼう from Tomohiko Himura タイトルの元ネタは言わずとしれた、「すごいH本」で知られる [すごいHaskell 楽しく]http://www.amazon.co.jp/gp/product/4274068854?ie=UTF8&camp=1207&creative=8411&creativeASIN=4274068854&linkCode=shr&tag=eiel-22() です。 良本なので、まだ読んでない方は、ぜひ。Haskell を使う機会がなくて新しい視点を得るヒントになるかもしれません。 LTは Haskell ともなんにも関係ないし、説明する時間もありませんでした。 話を戻します。 つまり、広島は盛り上がってるのか、盛り上がってないのか。 どちらでも構わないから、もっと盛り上げたらいいよね。 そういう気持ちの話しをしてきました。 人前で話すのは本当に苦手です。 だからといって、何もしないのでは期待するような結果にはならないです。 ならば、まずは自分にできそうなことをやる。それだけです。 「地元がよいけど、やっぱ都会のほうが楽しいよー」って、人たちが「地元楽しいな!」になると良いですよね。 このセッションに便乗したわけではないのですが、すごい広島 という Meetup 的なものをはじめてみたりしました。 毎週水曜日にやってみようと思います。 おしい広島にもなんとなく音が近いですね。 Asakura.rb 的なものがやってみたかった。 実は参加したことがないのでどんなやり方なのか実はさっぱりわかっていません。 岡山でも Okayama.rb というのを毎週やっていて、対抗したい意識があったり、なかったりです。 やり方がよくわからないので自己流で裏テーマとして Github の使う ブログを書く週間をつける というのも兼ねてみてます。 「これは意識高すぎるんじゃね？」という意見もちょっと出てて、ちょっと迷い気味。 敷居もなるべく下げたい。 盛り上がりというのは、正のスパイラルで、そこからはずれてしまうと、負のスパイラルに落ちいってしまう印象があります。 良い方向へ進めばどんどん良い方向に進むと思います。 悪い方向へ進んだら、ゼロからやりなおせばいいです。 とりあえず、まずは周りから。