ネコになって本音を言えるWebサービス「Nyaaan」をリリースした！
みなさん、SNSやってると本音が言えないことって多くないですか？
たとえば・・・
- 彼氏/夫(彼女/妻)が好きすぎてつぶやきたいけど恥ずかしい
- こんな嫌なことがあったけど、SNSで書くと嫌なやつだと思われるかも…でも共感されたい
- もやもやってしてることがあるけど、うまい文章が書けないからつぶやかない
などなど。
Twitterの書込欄に文章は書くけど、つぶやかずそっ閉じってのは誰でもある経験かなと思います。
そんなときにみんな「にゃーん」とつぶやくのだと（勝手に）思ってます。
なので、「にゃーん」に意味をもたせてつぶやくことのできるWebサービスを作りました！
それが「Nyaaan（にゃーん)」です！
Nyaaan とは？
Nyaaanは、「ネコになって本音を言えるWebサービス」です！
なんだかもやもやした気持ちになってネコになって「にゃーん」とつぶやきたくなったらこのサービスを使います。
具体的に言うと、「Nyaaan」上の投稿欄になにかしたら書き込むと、Nyaaan上に「猫の鳴き声」でタイムラインに表示されます。
「ネコ語翻訳」機能を使うと、その鳴き声（にゃーん）に込められた意味を他の人でも見ることが出来ます。
そのままTwitterにシェアすると、Twitterのタイムライン上は「にゃーん」しか見えません。
そのかわりURLがそのツイートに載ってるので、そのURLを見るとNyaaan上で本音を見ることが出来ます。
詳しくはヘルプを見てください！
なので「本音を言いたいし共感は得たいけど広く見られたくないもの」がNyaaanを使うと発言できるようになります。
普段なら恥ずかしくて言えないことや愚痴をこのNyaaanで吐き出してください！
こだわったところ
とにかくネコ推しにしたかったで、随所にネコを散りばめています。
ネコのイラストは「イラストレイン」様からいただきました！
個人的には
- ユーザ登録のローディング
- 404画面
のネコGIFが気に入ってます。
今後の予定
このサービスを作って終わり ではなく育てていきたいと思ってます。
なのでゆっくりではありますが、追加機能はどんどん出していこうかと思ってます。
「こういう機能がほしい！」などありましたら、下記のTwitterアカウントにDMいただいたり
マシュマロから要望おねがいします！
自身の価値観の言語化
自身の価値観の言語化
人にはそれぞれの価値観があります。
その価値観に基づいて人は行動します。
さて、自分自身の価値観をあなたは理解してるでしょうか？
またそれを他人に説明することができますか？
自分自身の価値観を理解していないと
- いい仕事/会社に巡り会えない
- 自分に合う友人/恋人が見つからない
など、生活を豊かにしづらくなると思ってます。
こう書いてはいますが、僕も自身の価値観をうまく説明は出来てないなと思ってます。
なのでここで言語化してみたいと思います。
今回は仕事に関する価値観についてです。
ちなみに僕はソフトウェアエンジニアをやっていて、現在はSREという職種です。
たぶん適宜修正します。
エンジニアとしての価値観
- 事業の流れを止めない・加速・促進させるのがエンジニアとしてやるべきこと
- 技術だけではなく事業内容についても意見を言っていくべき
- ただ作るだけじゃなく、事業(製品)をより良くしていく思考・提案こそがエンジニアに求められるアウトプットじゃないかな
- 事業・チームに最適であれば最新の技術を投入していきたい
- 「使ったことがない」という理由でその技術を使用しない、というのは絶対やらない
- 成長の機会がなくなる
- 自分が事業の成長を止めてしまう
- 失敗はしてもよい
- 失敗は成功の母である by エジソン
- ただし2度以上の同じ失敗はNG
- 得た知見は外部にアウトプットするべき
- 業界に対して貢献できる
- 自身の市場価値向上につながる
- (会社としてアウトプットしてれば)ブランドの向上
- 外部の意見が得られる機会になる
- 繰り返し行う定形作業は自動化する
- よりビジネスロジックに注力して事業の成長を促進していくため
- 残業はしない(よほどのことがない限り)
- 1日の作業時間を決め、その時間内で作業を終えられるよう効率を考える
- 会社外の人と交流を大切にする
- 外部の知見を得られるという点で会社外の人との交流は情報収集の観点で大事
チームリーダーとしての価値観
上記のエンジニアの価値観にプラスして…
- 心理的安全性が担保されているチーム（組織）づくりこそがなによりも優先すべき
- ゴールを常に意識させる
- 定期的にゴールをチーム全体で確認する
- メンバーが腹落ちするまで話し合う
- 統一された意思は強い
- よほどのことが起きた際の残業などに納得感が得られやすい
- 定期的にゴールをチーム全体で確認する
- チームの共通認識を合わせるコストはちゃんと払う
- 振り返りは必ず行う
- チームで行ったことを振り返ると良い点・悪い点が洗い出される
- さらにそのことについてチームで議論でき、チームの共通認識とすることができる
- よってチームを強くすることが出来る
- タスクのゴールを明確にする
- 「この人いまなにやってるんだ？」という状況をなくす
- この状況をなくすと、チームの進捗状況が全員見えるようになり、仮に遅延してもメンバーから報告が挙がってくる
- 振り返りは必ず行う
- 属人化をなくすためのコストもちゃんと払う
- 自分がやってることで他の人がやれそうならさっさと権限委譲する
- 自分がSPOFにならない状況を作る(他のメンバーも同様)
- チーム外とのゲートウェイになり、メンバーには開発に集中してもらう
- 八方美人にならない
- チームメンバーであろうがチーム外の人であろうが「No」と言うべきときは言うようにする
最後に
あくまで僕の価値観なので、これを強いる気はないです。
僕は普段こういうことを考えて仕事してますよってことです！
同じような考え方の会社や同僚に巡り会えたら最高の環境ですね〜
では！
2018年9月振り返り
2018年9月の振り返り
仕事
アプリケーションのデプロイを自分以外がやれるように
Jenkins上でKubernetesを操作できるようにし、開発者にデプロイしてもらえるような環境整備をやってました。
あとは開発環境やSTG環境は夜間起動してるのは無駄なので、就業時間のみ起動するようなシステムを色々作ってました（これもJenkins）
上記のようなSRE系の仕事以外にも引き続きgolang + gRPCのAPI開発をやってました。
副業はCDNのFastlyのハンズオンを他社で講師としてやってきました。くらいです。
週1くらいのリソースくらいしか割けませんが、なんかお仕事あればよろしくおねがいします〜
ブログ
実績: 2記事
いろんなアプリを作った月だったなぁ。
勉強会
登壇
【オフライン】
実績: 0件
【オンライン】
実績: 0件
参加
【オフライン】
実績: 2件
- 2018/09/05 フリーランスエンジニアでプロジェクトを進めることについて考える会
- 2018/09/07 builderscon tokyo2018
【オンライン】
実績: 2件
インフラ勉強会に引き続き参加。
だんだん参加数が減ってきてしまっている。これは自分の勉強とかに時間を割いているせい。
読書
実績
読了: 1件 進行中: 2件
マネジメントの本を最近は読むようにしてる
その他
なし！
Markdownの表を簡単に作れるツールを作った！
Markdownの表って、作るのめんどくさくないですか？
こんな文字列を毎回作るんですよ？
| hoge | fuga | | --- | --- | | 1 | 2 |
そしてこういう表を作ってると以下のようなことが絶対あるはずです
- この列いらねぇ…消したい
- あ！この行と行、逆じゃん！
- 表が見づらすぎて死ぬ
そんな思いを毎回味わってたので、簡単にMarkdownの表を作れるツール「Markdown Table Creator」を作りました！
機能
このツールでは以下のようなことが行なえます
- 入力フォームに入力したらそれがMarkdownの表形式に自動変換される
- ドラッグアンドドロップでの行の入れ替え
- 列/行の追加
- 列/行の削除
- Markdownの表を貼り付けると、入力フォームで編集できる
最後の
Markdownの表を貼り付けると、入力フォームで編集できる
これがわかりづらいかもしれませんが、このようなMarkdownの表があった場合
教科 | 点数 --- | --- 数学 | 78 国語 | 90 理科 | 58 英語 | 80 社会 | 88
ツールの下部にあるテキストエリアに貼り付け、「Markdown to Table」ボタンをクリックすると…
このように入力フォームに反映され編集できるようになる機能です。
なので既存のMarkdownの表を簡単に操作できるのです！
使用技術
Vue.jsで作りました。HostingはNetlifyを使いました。
技術的に大したことはやってないのでそんなに語ることがなかったｗ
今回始めてNetlifyを使ってみましたが
今までFirebaseとかS3とかGitHub Pagesとか使ってきましたが、それらよりも遥かに楽で簡単でした。
もう静的WebホスティングはNetlifyでいいんじゃないかな。
最後に
今回作った「Markdownの表を作る」ってツールは、結構あります。
実際「markdown table」とかでググれば色々出てきます。
しかし今回作ったように並び替えができり、既存のMarkdownをうまいこと編集することができるツールはなかったです。（あるかもしれないけど！）
前回の記事でも書きましたが、すでに同じようなものがあっても臆せずに作ってしまって良いと思います。
大事なのは作りきって学びを得ること！
では！
Google検索した結果をハイライトするChrome拡張機能を作った！
Googleで検索したあとに、検索結果に出てきたページに遷移したとき
検索した文字列で再度そのページを検索することがたまにあります。
いちいちめんどくさいので、Chrome拡張機能で作ってみました！
機能
この拡張機能を入れると、以下のようなことができます。
Google検索した文字列を、遷移したページでハイライトしてくれる
これだけです！
オプションとしては…
- ハイライトの色を変更できる
- ハイライトする文字列を完全一致検索に変える
- ハイライト無効化
ちょっとわかりづらいですが
ハイライトする文字列を完全一致検索に変える
これは、例えば「time is money」とぐぐると、デフォルトでは「time」「is」「money」が別々にハイライトされてしまいます。
それが嫌な場合は、このオプションを有効にしてもらうと「time is money」という文章でハイライトしてくれます。
作り方
今回Chrome拡張機能をはじめて作りました。
以下の記事のテンプレートを参考に作成しました。
これを参考に作った拡張機能のソースは以下にありますので、参考にしたい人はどぞ！
Chrome拡張機能を公開する際に気づいたのですが、
ChromeのWebストアに登録する際には最初の1回だけは$5かかりました。
スパム防止用みたいですね、安くて助かりました(; ･`ω･´)
モチベーション
Chrome Webストアで「google highlight」とか検索すると、同じようなのが1件ありましたが
かぶってしまうとか気にせず作ってしまいました。（結果的にそんな被ってなさそうでよかったですがｗ）
こういうツールとかサービスはかぶりを気にして作ってしまうと、たいてい誰かが作ってしまってるのに気が付きます。
それがゲーム性とか特許に関連したものですと難しいですが、そうでない場合はかぶりは気にせずに勢いで作ってしまっていいと思います。
かぶりを気にしてしまうとなんにも作れません！！
大手でも二番煎じのサービスを投入して市場拡大を狙ったりしてますし全然かぶりはありです。
個人の場合は学習のためでもありますし、作って無駄になることはなにもないと思います。
最後に
Chrome拡張機能、はじめて作ってみましたが、html + css + JavaScriptで作れるってのをそもそも知りませんでした！
その素養さえあれば拡張機能を作るのは容易だとおもいます。
自分が作ったWebサービスを便利にするために拡張機能を作ってみる、という試みをしてみるのもよさそうだなと思いました。
あとバグの報告や機能追加の要望など気軽にDMなどください！！
では！
2018年8月振り返り
2018年8月の振り返り
仕事
引き続きgRPCのAPIをGolangで作ったり、Kubernetes + EnvoyでDEV環境やSTG環境作ったりしてました。
Kubernetesに関してはだいぶ知見が溜まってきた。
あとはDocker ImageもCircle CIで自動化などしたのでSREっぽい仕事もいろいろやれてます～
そういえばgRPCの.protoファイルからサーバー・クライアントコードを生成するの自動化したからその記事書きたいな。
副業は8月は特になにもしませんでした。
引き続き募集中です！！！
ブログ
実績: 2記事
書きたいことはいろいろあるけど、時間なくて書けなかった（言い訳）
勉強会
登壇
【オフライン】
実績: 1件
はじめて勉強会を主催しました。
2018/08/23 アニメから学びを得る勉強会 あにべん speakerdeck.com
【オンライン】
実績: 2件
2018/08/04 インフラ勉強会 wp.infra-workshop.tech
2018/08/12 インフラ勉強会 wp.infra-workshop.tech
参加
【オフライン】
実績: 2件
- 2018/08/07 Firebase Meetup
- 2018/08/23 あにべん
【オンライン】
実績: 6件
インフラ勉強会に引き続き参加。
読書
実績
読了: 1件 進行中: 3件
- カイゼンジャーニー
- エンジニアリング組織論への招待 進行中
- Go言語でつくるインタプリタ 進行中
- SRE サイトリライアビリティエンジニアリング 2週目 進行中
その他
ボッチサーチというWebサービスをリリースした
個人で開発・運営している「ボッチサーチ」というWebサービスをリリースしました！ bocchi-search.com
使ってる技術はアウトプットしないとな
OSSのライブラリやツールを評価するWebサービスを作ってる
すっかりWebサービスを作るのにハマってしまったので、新しいWebサービス作ってます。
GitHubのリポジトリをレビューするサービス作ってます！ pic.twitter.com/jZUfBu1E0c
— Morix💪😼✨ (@morix1500) August 31, 2018
今月リリース予定です！
自分の中の「SRE」を言語化してみる
僕はいま自分の職種を「SRE（Site Reliability Engineer)」と名乗っています。
こういうと「SREってなんですか？」とよく聞かれます。
一言で説明はしてみるものの、抽象的すぎて伝わっていない様子。
そして具体的に説明しようと思ったら、やってることが多くて説明が散らかってしまい伝わらない。
なので一度自分の職種を見つめ直し、ちゃんと言語化しようと思いました。
これから書くのは「Google」のSREとは違うかもしれませんし、みなさんの会社の「SRE」とも違うかもしれません。
あくまで僕がいままで学んだことや、やってきたことを基に考えた「主観」です。
※適宜修正していきます
SREを一言でいうと？
サービスの可用性を守るお仕事
どんな仕事をするのか
- 可用性があるサーバーアーキテクチャの検討・構築・運用
- 上記の構築の自動化
- キャパシティプランニング
- 安定したデプロイを行える基盤構築・運用
- 監視を行う基盤構築・運用
- サービスの状態を見るためのログ収集基盤の構築・運用
- 可用性につながるアプリケーションの開発・保守
- パフォーマンスチューニング
- オンコール対応
- 可用性につながるテスト実施（負荷試験）
- セキュリティの担保
- 開発チームの考案したアーキテクチャレビュー
- 開発チームのアプリケーションのソースコードレビュー
エンドユーザにとっての「SRE」の価値
- サービスをいつでも提供できること
- 障害が起きても即座に復旧できること
- パフォーマンスを向上させ、ユーザ体験を良くする
会社にとっての「SRE」の価値
開発チームとの関わり方
- 開発チームのリリースまでの流れを妨げてはならない
- よりリリースをスムーズにできる仕組みづくりが必要
- 例外もあり、ユーザ体験に難ありの場合は開発チームと話し合い止めることもある
- 可用性という観点で開発チームのソースコードやアーキテクチャをレビューする
- スケーラビリティを考慮していないアーキテクチャになっているときがある
- DBクエリー、N+1問題などパフォーマンスに影響のあるところを注意する
- 開発チームとSREチームはともに可用性という観点で同じ目標を持つ
- 対立構造を作らないため
最後に
こう言語化してみると、カバーしなくてはいけない技術が非常に多いです。
サーバーの構築・運用だけではなく、アプリケーション開発の領域まで踏み込むこともありますので
プログラミング能力は絶対に必要になってきます。
またアジャイルのように高頻度でリリースを行う場合、そのリリースを安定化させる仕組みづくりも必要です。
このような「可用性」を守るためにあらゆる努力をするのがSREだと思ってます。
これらの領域の学習をするのはとても大変ですが、がんばっていきたいと思います…！
いま1人でSREやってるんですが相談できる相手がいなくて辛いです(´・ω・｀)
SREの方はぜひお話しましょう！！
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/08/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
