Step-to-Rails-Expert.rb第一回を開催しました
Step-to-Rails-Expert.rb第一回を開催しました
Railsの中級者向け勉強会であるStep-to-Rails-Expert.rbの第一回を2016/11/7に開催しました。
step-to-rails-expert-rb.connpass.com
当日の流れは
- 勉強会の紹介
- 今日の流れ
- 見学者の紹介
- 自己紹介
- メンバーの自己紹介
- LT
- 議論(当日の内容はこちら)
- 感想・次回お題目リクエスト
という形で進めました。 議論では、認証機能がテーマということで、主催者のLTからスタートし(スライドはこちら)認証機能を実装する際に使ったことのあるGemのアンケートを取り、使ったことのあるGemについて良かったこと・使いづらかったことを話すという形で進めました(当日の議事録はこちらにあります)。 今回は神速さん(@sinsoku_listy)とぷりんたいさん(@spacepro_be)のお二人が中心的に話す形となりました。お二人が色々な知見を話してくださるので非常に参考になり、また主催者として会の進行の方でも助けて頂き大変ありがたかったです。 また、議論する時の情報の共有ツールをどうしようと思っていたところ、ぷりんたいさん(@spacepro_be)がHackMDを紹介してくれたので、非常に助かりました。 これはかなり便利なので、次回以降も使わせてもらおうと思います。
個人的な議論からの学びとしては、deviseがomniauthを依存関係に含んでいて、omniauth連携をしやすいのでdeviseが良いという点が非常に参考になりました(ログインしたまま投稿する/つぶやくといった機能を実装したことがなかった)。
初回にもかかわらず、素敵な会場で参加者も集まり、議論も進んでいたので非常に有意義な会になりました。
また、「中級者と銘打ったことで参加しやすかった・興味が湧いた」や「既存の勉強会(特にかなり実績のある勉強会)は出るのを躊躇してしまうので、若いコミュニティで出やすそうだった」という意見は、自分が本勉強会を開催する目的の一部だったので、素直に嬉しかったです。
前者に関して、レベル別の勉強会を開催しようとすると、どうしても初心者向けが多くなってしまうので、それ以外の選択肢のモデルケースになればという思いがありました。実際に実施してみて、いくつか課題を見つけたので、今後実施していく中で、その辺対処できたのかできなかったのか正直なところを書いて行きたいなと思います。
後者に関しては「学ぶに行くのだからそういう心理的な障壁も乗り越えるべき」というストイックな意見や「わかる」という意見が出ると思いますが、今回のメンバーに表参道.rbの主催者である神速さん(@sinsoku_listy)(間違っていたらすみません)、五反田.rbの主催者であるmikamiさん(@sukechansan)に来て頂いたことを考えると、他のコミュニティの主催者&スタッフの方と今まであまり勉強会に出ていなかった方が交流して、より(扱うトピックの)レベルの高い勉強会にも参加するきっかけを作るという貢献が出来るのではと期待を持てました。
言うまでもなく、「自分が学べる場が欲しい」という自身の目的はこれ以上ないくらい実現されていました笑
また、お世辞でも「次回出たい」と言ってくださる方が多かったのは何よりです。
そしてアニメイトラボさんのオフィスはユニークでかつ綺麗すぎるので、驚いている方が多かったです笑
会場提供してくださったアニメイトラボ様、ロゴを提供してくださったセラリンさん(@Selime_0123)、初回開催までお手伝いしてくれたお二人(@ttwo32さん、@KoukoMatsumotoさん) 本当にありがとうございました。今後とも継続的に開催していきますので、引き続き何卒よろしくお願い致します。
最後に、初回実施して課題がいろいろ見えてきたので、書き出しておこうと思います(内部の話や個人的な話を含みます)。
課題
毎回参加者のレベルが異なるが、LTの内容や議論の流れは想定するレベルによって異なる。
これを事前に把握することは出来るのか(すべきか)。例えば上級者枠・中級者枠を作ったり、基準を提示して事前にGitHubにあげてもらう?みんな発言するためにはどうすべきか
上級者が話すと黙ってしまう(聞いているだけで勉強になるというのは個人的にも理解できる)。しかし、上級者だけが話す形になり、話す人数が少ないと負担が増えてしまうのではないか。持続可能な進め方を考える必要がある。
また、中級者や、初級者に近い中級者の方も発言(質問)とかすることで、他の同じレベルの人も勉強になる部分があると思うので、ある程度発言してもらいたいし、そのためにはうまく話をふる必要がある。 話さない問題は、主催者の議論の進め方以外にも、ある程度の回数実施して、参加者の中で顔見知りができたり雰囲気がわかってくれば改善するのかも。あとは多分私の緊張が伝わってやりづらかったりしたと思う。 サービスを運営している会社と受託のみしている会社、両輪の会社、という勤めている会社による文化の違いとかも知りたいなと思うので、やはりいろんな人が発言するの大事。
この辺考えると、初中級・中級・上級というレベルの基準をこちらから提示して、事前に提出してもらい、また、自己紹介で提出したレベルを言うようにしてもらい、自分で把握できれば、話が振りやすくなり、結果的にいろいろな人が発言できるようになるかも。
反省点
今回の参加者レベルでは、LTはもう少し踏み込んだ内容で作るべきだった。ただ、やはりその対応をするためには事前にレベル感の把握が必要。
話が切れた時用の議題をいくつか用意しておく メインテーマの他にサブテーマをいくつか用意しておく。 サブテーマを後出しにしておくと、私の精神衛生上よくなかったり、無駄にその話を(私が)引き延ばそうとするインセンティブが生じるので、事前にサブテーマを公開してサブテーマが尽きたら自由時間という風にすれば良いかな。初回の様子を見ていると、その状態になっても各々席の近い人やレベルが合う人と話をするだろうと予想できるし、話をしない人は他の人の話を聞けるので(懇親会状態)、他の人の話を聞いているだけでも嬉しいという人のニーズも満たせるし、少なくとも(私が)無理やり話す伸ばすより健全だと思う。どうしても形式上、その場にならないと予期できないことがあるので、精神衛生上割り切りも必要。
ハッシュタグ考えてなくてすみません。準備不足でした。つぶやいてくれている方いたので、申し訳ないです。次までに考えておきます。
勉強会紹介のスライドを作る
スタッフについて
@ttwo32さん、@KoukoMatsumotoさんに初回開催まで手伝ってもらっていました。 最初は「意見もらえたら嬉しいな」くらいのイメージで考えていてました。もしやる気があるなら色々仕事もしてもらいたいなとも考えていましたが、そもそも無償でお手伝い頂いているのでお二人の無理のないようにしてもらうというのを最優先にして、自主的に手伝ってくれたところ以外のこと基本的には私がやるようにしていました。ただ、当初は開催まで時間があるので、そんなに(期限的に)負担になる仕事にはなってなかったのではないかと想像しています。一方、私としても割と良い感じに仕事を振れて、ありがたいなと思っていました。
しかし、開催が近づくにつれて、仕事量も増えていきお願いしたいことも増えましたが、同時に仕事の重さ(期限を切る必要が出て、「土日にやります」が難しい時がある)が増してきてあまり気軽にお願い出来なくなり、お願いすることがかなり減りました。というのも、期限を決めたり、成果物をチェックする必要があり、仕事を振ることでのお互いの負担が増えるだろうと考えていたからです。
そのような経緯で、お二人の立場をどう扱うべきか、という迷いが生じました。正直、スタッフとして扱うならもう少し仕事を振ることになるし、その結果色々厳しいことを言う必要性も生じるでしょうし、あまりご負担をかけたくないなというのが本音でした。
この意見を素直に伝え、「このままの関係もしくは純粋に参加者としての関係と、スタッフとしてしっかり入ってもらうのどちらが良いか」聞いたところ、@ttwo32さんはスタッフとしてやってくださることとなり、@KoukoMatsumotoさんは「当面は参加者として陰ながら応援します」ということで、純粋に参加者として参加して頂くことになりました。
ただただ私が作業見積もりをできておらず、きちんと最初にどのような関係性にするかを決めなかったのが悪いのですが、2人ともきちんと話を聞いてくださり、冷静に判断してくださったので本当に感謝しています。@KoukoMatsumotoさんは主にTwitterでの会場の募集、@ttwo32さんは議論内容に関する企画を主にやってくださり、初回開催に大いに貢献してくださいました。本当にありがとうございました。
@ttwo32さんへ、引き続きよろしくお願いします。知識豊富で心強いので、色々アドバイス頂けると嬉しいです。 @KoukoMatsumotoさんへ、BtoBの文化の話も聞いて見たいので、またきてください!
最後に
来月は12/5に開催予定です。connpassで募集しますので、是非ご参加ください!
OSS Gate(2016/07/30)に参加してきました
OSS Gateに参加してきました
OSS Gate(2016/07/30)にビギナーとして参加しました。 oss-gate.doorkeeper.jp
OSS Gateの詳しい説明は以下の記事に書いてあるので参照ください。
oss-gate.github.io kenhys.hatenablog.jp
感想
流れや実際にやっていることは他に書いてくださっている方がいるので、主にビギナーとして参加した感想を書きたいと思います。 私はビギナーとして参加したのですが、「本当に誰でもOSS開発に参加できるんだ」という感想を抱きました。
理由として、まず、経験者の方が実際にどのようにOSS開発に参加しているのかを体験することで、ハードルが下がりました。 ドキュメント修正のプルリクを実際に送るところまで体験できましたが、実際の体験だけではなく「その過程でどのような作業をすべきか」というところを教えて頂けたのはとても勉強になりました。
もう一つの理由として、OSS開発にも色々な役割があると意識できたという点があります。 設計/実装だけでなくドキュメント整備も大事な役割であり、ここは開発者の手の回らない箇所で初心者が役に立てる場所でもあります。 皆さんも経験があると思いますが、自分の開発に関するドキュメントは、自分が作り理解しているが故に穴のあるものになってしまうことがあります。 作成する時間がなくきちんとドキュメント化できないケースもあると思います。
さて、このOSSを使用することになると、公式ドキュメントに必要なことが網羅的に(さらには親切に)書いていないので、ハマることになります。 当然ググって解決策を見つけ進めることになります。ある人はブログに書き、またある人は自分だけの知識にしたまま、時間が経ちます。そして、また同じ轍を踏む人が現れます。・・・この繰り返しが起きるわけです。 しかし、本来「ハマってググる」作業は必要ない作業で、最初にハマった人がREADMEを修正すれば、他の人は「ハマらずに」進めることができたのです。
偉そうに書きましたが、このような心構えはOSS Gateに参加するまで私にはありませんでした。 でも、確かにドキュメントが分かりやすく書いてあれば嬉しいですし、その部分こそOSS開発初心者がOSS開発に参加するチャンスなのです。
例えばインストールでハマった場合、依存関係が足りないなら「何を事前にインストールする必要があるか」をREADMEに追記し、MacOSに関するインストール方法は書いてあってWindowsの方法は書いておらず 辛い思いをしたなら、READMEに不足しているOSの情報を追記すれば良いのです。ドキュメントが「自分のような初心者にとってわかりにくい」なら、初心者が分かりやすいように修正してあげれば良いのです。
こうすることで、同じ原因でハマる人は減りますし、最初から開発(設計/実装)の面で参加するよりハードルが低いと思います。
上記で書いた内容は「他人のため」という側面が大きいですが、もちろん本人にとっても良い面があります。 まずドキュメント修正レベルから開発に参加することで、参加していない時より開発をウォッチするインセンティブになり、 OSS開発の動きを学べたりコードを読む時間が増えたり、参加していない時よりも主体的に見られるようになると思います。 勉強やスキルアップのためにOSS開発をウォッチしたが飽きてしまった、もしくは漠然とよく分からなかったという人がいたら、ドキュメント修正レベルからOSS開発に参加し いろいろ学んでいくことをお勧めします。
最後に
メンターの方々、企画の方々本当にありがとうございました。
9/24に次回のOSS Gateが開催されます!メンターの人数が足りないそうなので、ビギナーの方だけでなくメンターでの参加も是非お願いします! oss-gate.doorkeeper.jp
レポート: 【ランチセッション】クラウド時代のソフトウェアアーキテクチャ
登壇者
西谷 圭介様(アマゾン ウェブ サービス ジャパン株式会社 技術本部 ソリューションアーキテクト)
The Twelve-Factor App
codebase
- バージョン管理は当たり前、1つのコードベースから複数のアプリができるのは良くない
依存関係
- 環境に依存しないこと
- 依存関係を明示的に分離
設定
- 設定はOSレベルの環境変数に入れる
並行性
- スケールするときはプロセスごと増やす
マイクロサービス
hexagonal architecture
- 特定ポートに届いたイベントをアダプターがアプリに渡す
- アダプターがメッセージのやり取りをする
ヘキサゴナルアーキテクチャ日本語翻訳ページ http://blog.tai2.net/hexagonal_architexture.html
マイクロサービスのポイント
- 各サービスは独立、単一でデプロイと実行が可能
- 分割単位はビジネスの境界やビジネスの遂行能力で分割する(技術的なものではない)
- プロトコルはhttpでRESTfulのケースが多い
- 各サービスごとにスケーリングできる
Polyglot Persistence
- 各サービスごとに最適な言語とDBを組み合わせる
- 検索: elasticsearch
- ソーシャルデータ: Neo4J(グラフDB)
- ユーザーセッション: Redis
Amazonの例
- Amazonも昔はモノリシックなサービスだった
- チームの体制がTwo Pizza Team理論に即した体制に変化
- それによりチームの体制がマイクロサービスの文脈へ
- 開発チームは小さく、それぞれのチームが開発した単位でリリースできる
アプリケーションの実装パターン
Graceful Degradation
- 500エラーは返さない
- 一部にエラーがあっても全体の停止を起こさずその他の機能は有効に動くようにする
- 例えば、ECサイトのリコメンド機能がダメな場合でも、トップページにアクセスしてもページが表示されるようにする。おすすめ品が表示されなくても、全部表示されないよりマシ。
Fail Silently
- 外部向けには、エラーコードを返さない。
- 内部できちんとロギング、監視すること。
retry
- 失敗は一時的なものが多く、リトライすることで成功することが多いため、リトライする処理を入れる。
- 間隔の調整はフィボナッチ数列、exponetial back offを利用する。
curcuit breaker
Smooth internal traffic
マイクロサービスの考慮点
- 分散したコンポーネントを扱う難しさ
- レイテンシー
- トランザクションが複数のサービスをまたぐことがありえてしまう
- 西谷さん個人の考えでは、プロダクトが小さい場合はマイクロサービスのデメリットの方が目立つ
トランザクション
- 複数DBでデータが同期されている必要性
- 結果整合性の導入
- 状態変化に合わせてイベントを発行する
- イベントをsubscribeし、イベントドリブンに処理を行う
- 一時的なconsistencyの妥協
イベントソーシング
- 状態でなくイベントを追加するという考え方
- イベントのリプライにより現在の状態を導出できる
- スケールしやすい(キャッシュが楽)
- イベントドリブンでは、状態を変更しイベントを追加するが、これはイベント追加のワンアクションで済む
CQRS
- DDDの文脈で登場
- 更新処理と参照処理の分離
- 更新処理は正規化、クエリは非正規化の方がいいなど差異が大きいため
RESTfulAPI
ステートレスは他の店員になっても問題無し→スケーラビリティが高い
AWSでどうマイクロサービスを実現するか
- 満たすべき要件は自動化と自動化のためのAPI
- インフラは何でも良い
感想
アプリケーションの実装パターンやイベントソーシングという考え方など、知らないことが多く非常に勉強になりました。
昨日からAWS Summitに参加しマイクロサービスのセッションを拝聴していて、マイクロサービスの難しい点として「分散したコンポーネントを扱う難しさ」が共通して上がっていました。また、本セッションで挙げられたトランザクションやデータ同期も確かに悩ましい問題で、西谷さんが個人的には「プロダクトが小さい場合はマイクロサービスのデメリットの方が目立つ」とおっしゃっていた理由もよくわかる気がします。ビズリーチさんのマイクロサービスに関するインタビューでも竹添さんが同じようなことをおっしゃっていました。
開発のときのオーバヘッドや、インフラコストで見ると、短期的にはデメリットのほうが大きいと思っています。どこかで損益分岐点はあると思うんですが。とりあえずスモール仕立てでやってみようとか、成功するかまったくわから状況なら、モノリシックで作って、後から大きくなったタイミングでマイクロサービスにしてもいいのではないでしょうか。
非常にためになるお話をありがとうございました!
参考
html5experts.jp 12factor.net ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳) AWS Summit Tokyo 2016 Developers Conference(DevCon) - アプリ開発・IoT の最新トレンドが集う2日間 - 2016年6月2~3日 グランドプリンスホテル新高輪 飛天会場にて開催
レポート:【パネルディスカッション】Slack, Qiita, GitHub 利用者 & 提供者の視点で見る、クラウドとツールの使いどころ
はじめに
AWSSummit 2016の「【パネルディスカッション】Slack, Qiita, GitHub 利用者 & 提供者の視点で見る、クラウドとツールの使いどころ」の内容をまとめたレポートです。セッション動画が公開されると思いますが、さしあたり参考になれば嬉しいです。
注:ですます/である調が混在しているのでご了承下さい。大きく聞き逃したところもあり、その点は記載してあります。 内容に誤りがある場合は指摘して頂けると嬉しいです。
本編
登壇者紹介
パネリスト
【Slack 利用者】岩瀬 義昌様(エヌ・ティ・ティ・コミュニケーションズ株式会社 技術開発部 エンジニア
【Qiita 提供者】髙橋 侑久様(Increments 株式会社 CTO)
【GitHub 提供者】藤田 純様 (ギットハブ・ジャパン合同会社 カントリーマネージャー)
モデレータ
吉羽 龍太郎様(Ryuzee.com)
なぜこれらのツールやクラウドが受け入れられたのか
岩: チャットは昔からよく使われていた。irc hipchatなどあるが、slackは開発者の相性が良い。integrationが豊富でapiが公開されていることが重要。
吉: apiの影響が大きいとうことでしたがその辺どうでしょう。
髙: qiitaチーム、slack、githubは連携ができるというのが大きい。親和性が重要。
藤: api連携をしており、ユーザーがどんな問題を解決したいかが明快で、特定のドメインの問題を解決するに集中できる。 ほかの分野は連携するという感覚で、これがスピード感に繋がり受け入れられたのでは。
岩: 議論がslackで盛り上がった場合、slackはフローの情報でqiitaはstockの情報だが、フローの情報の共有はどうしているか。
髙: slackでというよりは、オフラインの会話をオンラインに持っていくというのが大事だと思っていて、良い方法を模索中。
藤:半分がリモートなのでリモート前提。オフラインの情報は、オンラインに残すように習慣づけるようにすべき。
受け入れられた背景、ビジネス的側面
藤: スピードだと思う。PCDAがあるが、Pの部分がすごく重いので動きが遅くなってしまったり、また、Pが一度決まるとそれを100%守らなければいけなくなってしまう。どうせやってみなければわからないんだから、早くトライして速く失敗して学ぶことが重要で、それを許容する心が組織には必要。
岩: 研究職は早く失敗するというのを求められている。本来やるべきことに集中するためにツールが大事になってくる。
ツールとクラウドの親和性
藤: 本業に集中するという観点から、繰り返しの同じ作業に関してはツールに任せることが大事で、CIなども同じ考え方だが、スピードを上げるために本業に集中し、組織としても強みを発揮する。ツールとクラウドの親和性はスピード、本業への集中。
(筆者:この間の話は聞き逃してしまいました。)
髙: オンプレミスが必要な理由は、結局社内の事情で、スピード感がなくなる。
吉: 逆にクラウドだからこその辛みはあるか。
藤: どこに情報を置くかというのが企業によっては問題になるので辛い。
吉: セキュリティとかポリシーとかですかね。そのような障壁がある場合、どうやってクラウドを導入していけばよいのでしょうか。
岩: エンプラなので導入ハードル高い。社内に通す時、偉い人よりミドルマネジメント層で技術のわかる人を巻き込んで行動した方がいい。slackの時は導入して使えることがわかると偉い人も使い出した。
吉: ラインの偉い人はそれで通るかもしれないが、例えば専任のセキュリティ担当と折衝するケースではどうだったか。
岩: お客様情報など重要な情報に関してはオンプレミス。qiita:teamなどは漏れてもokな情報しか書かない。 お客様の名前など出ていないか最初はチェックしていた。
髙: 導入に関して、ミドルマネジメント層のわかる人を巻き込んでやった方がいいが、いない場合もある。 導入して勝手にそのツールが広まることはないので、率先して使い広める人が必要。
吉: 社内エバンジェリストのような人が必要かな。でも一人だけだと辛い。
岩: 折れてからが勝負!
藤: 導入に関しては、社内のスターを巻き込んで使ってもらう。基本的に組織を管理する人たちにとって、みんなんが幸せに仕事してもらえれば嬉しい。ある例だが、現場からgithubムーブメントが起こり社内に広まった。導入された後に、スターたちが偉い人にお礼のメールをしたら「あ、こういうのが嬉しいんだ」と偉い人が理解したというケースがある。コミュニケーション大事。
岩: 社外コンサルに頼るという手もある
藤: とりあえず試すことが大事。
吉: 評価する前にとりあえず使うことが大事なんですね。
髙: あるツールを使うというよりは、既存の導入しているツールと連携させるイメージで使うような感覚で使うと定着する。
岩: kpiを求められた場合は?
吉: 人件費が一番高いので、今あるリソースを本業にどれだけ避けるようになるかを説得する。
藤: 数字だけでは理解できないものがあるので、その部分をアピールすることが重要。
吉: 合宿みたいに集まって、偉い人も集めて、作っているところを見せて理解を得たことがある。
吉: 言い残したことは?
岩: 内製頑張りましょう!採用にも繋がるので、ブランディングが大事。
髙: 他のツールを敵視(ライバル視)していない。それよも、情報共有の重要性が浸透していない問題に対し一緒に解決を試みる仲間と思っている。 情報共有の重要性に関する世論を形成したい。
藤: 経営資源は遜色ないけど、なぜこんなに外国と差がつくのかという話を聞くことがあるが、失敗を許容するマインドがないというのが大きな違いではないかと考えている。髙橋さんが「ムーブメント」と言っていたが、失敗してもいいムーブメントを起こしたい。不確実性の中、一寸先は闇なので、失敗することは悪ではない。
最後に
登壇者の皆様、非常に興味深いお話ありがとうございました!
参考
プロフィールは以下の詳細ページから取得しました。
http://www.awssummit.tokyo/devcon/index.html
JAWS-UG CLI専門支部 #38に参加してきた。
JAWS-UG CLI専門支部 #38 - 初級者歓迎 復習編: S3 + 静的Webホスティングに参加してきました。
JAWS-UG CLIの勉強会に参加しました。 jawsug-cli.doorkeeper.jp
JAWS-UG CLI専門支部とは
JAWS-UG CLI専門支部とは、AWS CLIの勉強会で、AWSのサービスをマネジメントコンソールからではなくCLIを使用して扱うことに特化した勉強会やイベントを開催している組織です。これまで3度ほど参加させて頂いていたのですが、「初級者歓迎」の回に参加するのは初めてでした。
流れ
メモ
CLI専門支部についての説明
Query(--query)
- 出力結果から特定のノードを取り出すことができる
- jqの代替 JAMES-Path表記
- describe系のサブコマンドのfilterオプションで絞り込みをして、その結果からqueryオプションでノードを取り出す
補完は以下で行えるようになる(bashの場合)
complete -C aws_completer
jsonlint
- ヒアドキュメントでjson作るので壊れていないかチェックするために必要
CLIのupdate
S3の説明
- S3 はサービス名の頭文字がs3つだから
- EC2の後がS3で、この後は「何4」がでてくるのかと期待していたそうです笑
- オブジェクトストレージ(not ブロックストレージ)
- 動的コンテンツがなければS3のみで完結できる
- 動的コンテンツはcognitoとの併用で対応可
- URLをつけないとファイル置き場、つけると外部から見える
- URL自体をバケット名になるので、S3全体でバケット名はユニークである必要がある
- オブジェクトは最小単位、内部的にフラットだが、名前で擬似的に階層構造を表現できる
- S3 はサービス名の頭文字がs3つだから
cli s3コマンドの説明
- ハイレベルS3コマンドはデフォルト出力がテキスト形式なので注意
その他メモ
- cognitoと組み合わせて動的サイトも作成可能(cognitoでjsが動く)
- webサイトホスティングでは、最初にあげたファイルにのみアクセス許可が与えられている(ファイルごとに許可与える)ので、バケット自体に権限を与える処理が必要。ポリシーを自分で与える必要がある( 以下の2.*で設定http://qiita.com/tcsh/items/dd99e9f7ced6406f8818)
- コマンドの成功or失敗に関しては画面に何も出力がないことを確認するか
echo $?
をする必要がある。基本的に何も出力されなければ成功と思って良い。 - webサイトホスティングの際に、例えばindexページなどを認識させるためには以下のコマンドを実行する(参考の[JAWS-UG CLI] S3:#2 ハイレベルS3コマンドで静的Webホスティングより抜粋)
aws s3 website "s3://${S3_BUCKET_NAME}" \ --index-document index.html \ --error-document error.html
- バージョンによる挙動の違い
感想
今回は初級者向けということで、ゆっくりと進めて頂いたため余裕を持って進めることができました。他の回ではかなり急いでいた記憶があるので対照的でした笑。 初級者歓迎を冠していない回だとCLIを触ったことのない方は敷居が高いかもしれませんが、主催者の方も懇親会でおっしゃっていたように「出席して実行した結果を持ち帰ってもらえば後で復習できる」ので、出席してとにかく手を動かしてみるのが良いと思います。資料もかなり充実しています。 勉強会&懇親会ともに非常に楽しかったです。主催者の方、参加者の方々ありがとうございました。
参考
JAWS-UG CLI専門支部 #38 - 初級者歓迎 復習編: S3 + 静的Webホスティング - JAWS-UG CLI専門支部 | Doorkeeper
[JAWS-UG CLI] S3:#1 ハイレベルS3コマンドを使ってみる (バケットの作成から静的Webホスティング、削除まで) - Qiita
macのターミナルでvim使用時に、optionキーを押すとカーソルが十字に変わり任意の場所にカーソル移動ができる
macのターミナルアプリでvimを使用するときに、optionキーを押すとカーソルが十字カーソルに変わり、クリックした場所にカーソル移動ができます。
例えば、上記では「u」の二文字目にカーソルがありますが、この状態で「option」キーを押下したままカーソル移動したい文字のところでクリックすれば、その文字の箇所にカーソルが移動されています。
こういう子ネタ、以外と知らなくて恥ずかしいんですよね・・・
他には、viで画面が壊れたとき(Enterキーを押しても次のプロンプトが表示されないとき)にclearコマンドで直るとか、最近になるまで知りませんでした・・・恥ずかしいし知っていると便利なのできちんと勉強しないとという感じですね。
疑問点
macでカーソル付きのスクショを取る方法は以下のページに書いてあるんですが、十字カーソルのスクショを取る方法はあるのでしょうか。 どなたか知っている方いたら教えてくださると嬉しいです。 inforati.jp
AWSのELBへSSL証明書アップロード時に「Unable to parse key; the body is encrypted.」エラー
ELBへSSL証明書をアップロードする際に以下のエラーが出ました。
原因
- opensslで秘密鍵を作成する際に、パスワード設定し暗号化していたことが原因だった。
確認方法
- 秘密鍵を参照し、2行目・3行目に以下の内容がある場合は暗号化されている。
$ cat server.key -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,E3CB8B1CE0E5CBDF7819D18627823618 〜略〜 -----END RSA PRIVATE KEY-----
対処法
$ openssl rsa -in server.key -out server.key Enter pass phrase for server.key: # ←ここで最初に秘密鍵を暗号化したパスワードを入力する writing RSA key
- 秘密鍵の内容確認。Proc-Type、DEK-Infoの記述がないことを確認する。
$ cat server.key -----BEGIN RSA PRIVATE KEY----- 〜略〜 -----END RSA PRIVATE KEY-----
- 以上が終了したら、ELBに証明書をアップロードする。
参考
ELBへ証明書のアップロード方法を知りたい方は以下を参照下さい。