こんにちは。れとるときゃりー(@retoruto_carry)と申します。 AppbrewではPdM・デザイナー・フロントエンドエンジニアをやっています。 プライベートでは、個人開発でみんなのボタンメーカーというサービスを運営したりしています。 ほぼ毎週ツイッターのトレンドに乗るような、所謂「バズ系」のWebサービスで、月に50万人くらいに利用してもらっています。 ツイッターをやっている方は、なんとなく見たことある気がする人も多いのではないでしょうか？ みんなのボタンメーカー 今回は、その知見を活用し、お仕事で「LIPSショッピング」というコスメの買い物ができるサービスのバズキャンペーンの企画・デザイン・実装を行いました。 コスメクーポンガチャ ちょうどいいので、それを題材にして、再現性をもって「バズ」るサービスを作る方法について話していこうと思います。 キャンペーンはかなり好評で、ツイッ

個人でWebサービスを継続的に運用するのは金がかかってかなわんという問題がある 「個人開発」だと定義が曖昧なので自己資金かつ赤字のプロジェクト(Webサービス)ということにする。 そういうプロジェクトではプロダクトオーナー=自分、開発者=自分、予算管理者=自分というロールになるので予算管理者としてコストを図る必要がある(ここでいうコストはWebサービスを実現するアプリケーションのランニングコストのこと)。 通常はみんな自分の人件費を0として計算していると思う(逆にいうとそれが負債という考え方もできると思う)。 ただしメンテナンス時間とコストのトレードオフもあるので、人件費0ではあるけど有限の時間は別軸として管理しているのが普通だと思う。極端な例だと「コスト削減できるけどメンテナンス時間10倍になる」というのは避けられる。 仮に個人開発のプロジェクトの予算を月数千円から高くても1万円ぐらいか

今年入社の高卒の新人と雑談していて「会社の確定拠出年金のこととか何を選ぶのがいいとか分からない」という。集合研修でも制度そのものの解説はあったけどよく分からず、学校でも習わなかったので、漠然としか分からないと言っていた。 それで「自分はこういう理解で、こうしている」を整理して伝えることにしたのでそのメモ。結論としては「長期でインデックス投信」なのだけど、そこに至るバックグラウンド等も含めて説明したいと思った。 前提 そもそも趣味や仕事に注力したいので、株や不動産を一生懸命やりたいとは全く思っていない。 自分は普通の会社員で、その道のプロ（銀行員や証券マンやファイナンシャルプランナー）ではない。 大損は絶対に嫌だし、時間を遣いたくない。株の勉強とかもしたくない。 経済システム 現在は「産業資本主義」というOSで世の中が運用されている。 このシステムでは「富の総量が時間の経過で増えていく（右肩

この記事は、「継承と委譲はどういった性質の違いがあり、どういった基準で使い分けているか？」「インターフェースは何が嬉しいのか？」といった点に関して自分なりに言語化を試みたものです。 TL;DR 継承は子が親と同じ能力や責務を獲得する。委譲は子が親を単なるツールとして所有するだけで、能力や責務は同じにはならない。 子にとって親は単なるツールである場合は委譲を使うのが良い。継承してしまうと子が複数の責務を負うことになり、そのことによる不都合が生じる。 逆に、子が親と同じ責務を持つべき場合には継承を使う。委譲を使うと、子が親と同じ能力を持っていないことによる不都合が生じる。 インターフェースを使うことで責務の分離を強制することができる。インターフェースを適切に設計することができれば、改修時の影響範囲が最低限に留まるなどシステムの保守性や堅牢性が向上し、テストの容易性も得られる。 継承と委譲の違い

この記事では、以下のことを記載します。 はじめに（職務経歴書をMarkdownで記述、GitHubで管理する） GitHub ActionsでPDFを生成する md-to-pdfでMarkdown→PDF出力 手順 1. README.mdに職務経歴書を記述する 2. md-to-pdfをインストール、PDF出力するスクリプトを作成する 3. ワークフローを記述する 4. git pushでワークフローを実行、PDFがダウンロードできるか確認する おわり 参考文献 はじめに（職務経歴書をMarkdownで記述、GitHubで管理する） いままで職務経歴書をGoogle Docsで管理していたのですが、 普段Markdownに書き慣れているため、 「職務経歴書もMarkdownで書きたい」という衝動に駆られました。 また、以下の記事や、 職務経歴書をGitHubで管理しよう - Qiita

はじめに いつもは技術ネタなどが多いこのブログですが、珍しくプライベートな話を少し・・ 我が家に新しい家族が増えた話です。 育休 両親に頼らず育児する環境にあったので、育休取得を前提に会社と調整していました。 妻はつわりがひどく休職、からの産前産後休業（からの育休）ということでしばらくは完全2オペ体制で育児に臨みます。 生まれる前（妊娠初期） 妻はつわりが長かったので、自分も妊娠の比較的初期のころから生活の変化を意識することができました。 仕事はなるべく定時に切り上げ、家事に積極的に取り組み妻の負担を減らすべく行動しました。また勉強会などの参加の頻度も減らし、参加するときは妻と認識を合わせ、家事もあらかじめする、など「調整」をしっかりすることを心掛けました。 ドラム型洗濯機、ロボット掃除機などはすでに我が家は導入済みだったので、そもそもの家事が少ないという点は良かったです。 よく「妻が先に

追記 本記事で紹介する「Chaplus雑談対話API」の後継となるAPIを公開しました。下記の記事で紹介をしているので、合わせてこちらもご覧ください。 https://qiita.com/maKunugi/items/14f1b82a2c0b6fa5c202 本記事で紹介するAPIよりも精度が向上している他、文脈を考慮した会話ができるようになっています。 対象読者 チャットボット等を初めとする「対話型」のサービスに興味がある方 チャットボット等の開発に興味がある方 チャットボットに雑談を話させたい方 対話システムと人間の対話に興味がある方 チャットボットに必要な「雑談力」 こんにちは、maKunugiです。 チャットボットを初めとする「対話型」のサービスが様々な場面で活用されている昨今ですが、対話型サービスの開発で非常に厄介なのが、「ユーザからの問いかけに応答するためのセリフを用意しきれな

ついに2020年になってしまった。 この10年はとにかくネイティブアプリ開発にすべてを投資した。 京都GTUGのイベント情報によれば、第1回Androidハッカソンは2009年9月5日に開催されている。このハッカソンのためにドコモ HT-03Aを契約しに行ったのがAndroidとの出会いだった。当時APIレベル3、コードネームCupcake、バージョン1.5である。加速度がホントにJavaのコードから取れてびっくりしたのを覚えている。 実に丸10年の月日が過ぎた。スマートフォンの普及率は20-30代で90%を超え、今後も低くなるということはないだろう。当然、それらスマートフォンで動作するネイティブアプリ開発の需要もしばらくは続くに相違ない。ただし、開発の前線から見える情景は少しずつ変わってきているようにも感じられる。 3-4年前だとネイティブファースト（特にiOS）が当然であり、ウェブが存

直近1年ほどで人生が大きく動いたので、忘れないうちに文章にしておこうと思います。 よくある転職の話です。 昔を振り返ってみると、僕はあまり学問に興味があるタイプの人間ではありませんでした。 ろくすっぽ勉強しないまま小中と進学し、高校受験に際しても無勉強で高専に挑んで当然のように落ちたりしてました。 中学の半ばあたりでCSに興味が芽生えたのですが、その興味を勉強という行動に結び付けることができず。単にコードを書いて遊んでただけ。 いい大学に行っていい会社に就職するんだというお話は、進路を決めるための折々の機会に、繰り返し学校の先生方から聞かされたのですが、そのお話の意図するところを掴めなかったのですね。 そうして僕は選択したわけです。いい会社に就職する…どころか、進学すらしないという選択を。 いい会社に就職できなかったケース 家業手伝い（農業） 僕は農家になりました。 農業は最高！ 植物は勝

Cloud Firestoreで「いいね」機能を実装するときの勘所Tuesday, December 31, 2019 何かしらのサービスを作る際に、ユーザー同士のコミュニケーションを促進させる機能の一つに、 TwitterやInstagramなどのサービスでおなじみの「いいね」機能があります。 機能としては 投稿等に「いいね」をつけることができる（♡だったり☆だったりシンボルは様々) 「いいね」がどれだけついたか、その数がわかる (最近だとInstagramがいいねの数の表示をなくしましたね🤔) 投稿等に「いいね」をしたユーザーの一覧が見れる 自分が「いいね」をした投稿等の一覧が見れる といったものが挙げられます。 このような機能ををFirebase、Cloud Firestore(以下Firestore) を使って実装する場合、 どのように実装するのか、どのような設計が良いのか、 逆

「言いたいことはあるけど言わんとこ」ってなることあるよね。言わなくて正解ってことももちろんあるんだけど、仕事の中でそういうのが積み重なるとストレス溜まるし、自分が逆の立場だったらどんなことでも言ってもらいたいのでなるべく言うようにはしている。 この意見はあるんだけど言わない/言ってくれないケースっていくつかパターンがあると感じているので、今後改善したくなった時のための整理としていくつか書いておく。 諦めている (今さら言っても仕方ないし) 言わんとこ (言ってもどうせ変わらんだろうし) 言わんとこ 気遣いしている (言ったら変な空気になりそうだし) 言わんとこ (時間押してるから長引かせん方がいいし) 言わんとこ (今ここで話すと誰かが嫌な気持ちになりそうだし) 言わんとこ (相手が感情的になっちゃいそうだし) 言わんとこ 線引きしている (○○さんが説明するべきだと思うし自分は) 言わん

2019/12/23時点で20アプリに対応しており、ウリとしてはお目当てのキャッシュレス決済アプリをすぐに利用できるようAndroidの通知領域からワンタップで開けるようにしているところです💪 えぇ.... ・稼働組 LINE Pay 楽天ペイ PayPay Origami Pay pring d払い Amazon Pay Pay ID pixiv PAY Sma-sh Pay EPOS Pay ＆Pay atone 銀行Pay ・参入予定 メルペイ ゆうちょPay 7pay Bank Pay au PAY ファミペイ Payどん←New!（鹿児島銀行：独自開発） — Hiroaki Yamashita☀️ (@HiroakiYamashi) December 27, 2018 ここからは実際の数値がどうだったのか振り返ってみようと思います。 3ヶ月ごとのQに区切って振り返り、最後に通年

君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、

この記事はSHIROBAKO Advent Calendar2019の記事である。 adventar.org 16話『ちゃぶだい返し』の小笠原さんのこの台詞がめちゃくちゃ好きだ。 「お酒を飲めば誰でも気分転換になると思わないでください。そういうことが苦手な方もいるのをお忘れなく」 言っている内容自体も好きなのだが、後輩を思っての台詞であること、気まずい空気になるのをわかった上で同僚に向かってはっきりと"それは違う"と主張していることが本当に素晴らしい。 何かを主張し、相手に納得して動いてもらうのはとても難しいことだ。言いたいことを言うだけで相手に動いてもらえると考えるのはアカチャンと一緒である。大人なら相手に動いてもらえるように言語化し、相手との関係やタイミング、伝え方も考慮しなければならない。 SHIROBAKOには、そういった自分の意見をしっかりと相手に伝えるシーンが多々出てくる。中で

2016年4月に新卒で入社したヤフー株式会社を退職しました。 おしらせ： 私事ですが、現職を11月末付で退職します。2016年4月の入社から約3年間半、本当にお世話になりました。引き続きiOSアプリ開発をやっていく予定です。今後ともよろしくお願いいたします。 pic.twitter.com/bKenNQgvF1— kumamo_tone (@kumamo_tone) 2019年11月21日 半年の丁寧なOJT形式の研修のあと、主にiOSとAndroidアプリの開発を担当させていただきました。期間としては3年と8ヶ月になりますが、かなりいろんな経験ができて、成長できたと思います。Yahoo! JAPAN アプリをはじめ、多くの人に使ってもらえるプロダクトの機能開発に携わったり、新規プロダクトの開発に携わったり、社内ハッカソンで数人チームでプロダクトを作ったり、大小様々な規模の開発に携わること

TL;DR 株式会社グロービスに入社した。元気に生存中。押忍 はじめに 2019年4月1日から新卒エンジニアとして株式会社グロービスに入社しました。 普段は、グロービス学び放題というビジネスを動画で学べる学習サービスを開発しています。 hodai.globis.co.jp RailsやGraphQLを書いていることが多いです。GraphQL-Rubyを最新に保ちつつ、アプリやフロントのエンジニアが楽しく開発できるスキーマについて考えています。 人生の転機に読み返して、価値があるように出来るだけ省略することなく書いているので長々しい文章となっています。まあ、読みたい人は読んでという感じです。 グロービスとは 学生は、知見録というメディア。社会人は、MBAを思い浮かべるのではないでしょうか？ globis.jp mba.globis.ac.jp 他にも、ビジネス書籍の出版、ベンチャーキャピタル

俺だ、kinoppydだ。今日はお前にSmartHRで働くということはどんな感じなのかを伝えに来た。 このエントリは、なにか悪い力によって書かれました。 ただしいエントリは下のリンクを参照して下さい。 tech.smarthr.jp SmartHRという会社 社会の役に立つものを作っている。そういう認識をしておけばだいたい間違っていない。 紙、好きか？　俺は好きだ。紙の質感は指に心地良いし、何より紙にはだいたい有益な情報が書いてある。俺は情報も好きだ。 だがしかし、それが年末調整や入社手続きなどの書類になると、話は別だ。俺は途端に紙が大嫌いになる。 何故か。必要ないからだ。必要ないだろ？　今の時代、政府だっていーがぶとか、でじたるとらんすふぉーめーしょんとかいうやつで、紙じゃなくても手続きできるようになってるんだ。 ペーパーレス。最高じゃないか。俺は紙が好きではあるが、紙を右から左に送った

先日、twitter上で食べログの星の数について、 ある問題が話題になりました。 食べログの闇として話題になったその問題とは、 「評価3.8以上は年会費を払わなければ3.6に下げられる」 というものです。 食べログは飲食店についての口コミを集めるサイトで、 その評価は実際のユーザーによって形成されるものとして広く認知されています。 専門的なグルメリポーターでもなく、 一般の人々の素直な感想を集めることで、 その飲食店のリアルな価値が知れると期待して、 利用しているユーザーも多いでしょう。 それだけに、 「食べログが評価を恣意的に操作しているかもしれない」という話は、 瞬く間にネットで話題となりました。 さて、この話は実際に行われていることなのでしょうか。 食べログでは、当然評価点は公開されているので、 このような恣意的な操作があれば、 何らかの形で偏りが見つかるはずです。 ということで、食

ファックスってゴミですよね。 そもそも『紙不敗神話』みたいなの信じてる奴ら未だにいるけどなんなんだよアレ。なにが、 「紙でもらわないと不安」 だよいい加減にしろ。そのお前の紙に対する絶対的な信頼はどこからくるんだよ。紙なんざ火ィ付けたら一発だからな。ペーパーレス、データ社会最強だから。だってデータはサイバー空間にあるんだからサイバーに。サイバーって無限なんだから。消してもすぐ復活できるんだから。紙？あんなもん破ったら終わりだろ。人間である俺から言わせたらザコですよザコ。100回ケンカして100回圧勝する。 思念でピッ！てやったら相手の脳内にシュッ！って直で情報が届くようになる時代がすぐそこまで来てんのにいつまでファックスとか使ってんだよ。昔わけわかんねぇ取引先のジジイと電話してて、 「口頭だと分かりにくいのでメールアドレスを紙に書いたファックスを送ってもらってもいいですか？」 やばぁなにコ

正確には「株式会社グロービスにエンジニアとして入社して3ヶ月が経ちました」です。 晴れて試用期間が満了したことと、同日‪の4月1日に入社して同じチームで働いている‪ @mktakuya ‬が入社エントリを書いたので後に続こうというお気持ちです。 blog.m6a.jp あと、つよつよエンジニアの転職エントリはそこらに転がっているけど、そうではないエンジニアの転職エントリも僕は読みたいなと思ったので自分で書くことにしました。 で、誰？ @shifumin 新卒で地元のジャパニーズトラディショナルローカルガバメント(notエンジニア) -> 小さなWeb系受託開発会社 -> グロービス Railsエンジニア 主にAPIを作ったりデータモデリング周りを触っていた グロービスに入社してReactも触り始めた グロービスという会社 recruiting-tech.globis.co.jp グロービス