非エンジニアの採用担当者がwebエンジニア採用を任されたらやっておくと良さそうなこと - razokulover publog
「非エンジニアの採用担当者がwebエンジニア採用を任されたらやっておくと良さそうなこと」という文章を社内向けに書きました。 経緯としては新しく入社した採用担当の子から「 書類段階で面談する方を選ぶ条件 エンジニア採用にあたってやっておくと良さそうなこと はありますか？」という質問を受けたので書いたものです。 全然体系立っているわけではないですが、社内に限定しておく内容でも無いですし、公開しておくともしかすると役に立つという人もいるかもしれないので記しておきます。 ちなみに想定している採用担当者のリテラシーはTwitterをちょっとやっている・NewsPicksとかYahoo Newsを通勤中にちょっと読んでるくらいを想定しています。 以下"エンジニア"と書く場合はwebエンジニアを指しています。 書類段階で面談する方を選ぶ条件 実際に自分で手を動かしてコードを書いてるというのが職務経歴から
Zalando RESTful API and Event Scheme Guidelines
Zalando’s software architecture centers around decoupled microservices that provide functionality via RESTful APIs with a JSON payload. Small engineering teams own, deploy and operate these microservices in their AWS (team) accounts. Our APIs express most purely what our systems do, and are therefore highly valuable business assets. Designing high-quality, long-lasting APIs has become even more cr
1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
リニューアルして卒業させる勇気｜林伸次
「飲食店の寿命は６年」という説があるんですね。 パンケーキでも、立ち飲みバルでも、スープカレーでもなんでも良いのですが、「え！ それ面白そう！ 行ってみよう！」って思われて、みんなが通ってくれるのって６年くらいが限度なんです。 まあ６年くらい経ってしまえば、「ああ、そういうの流行ってたよね。なんか懐かしいなあ」って気持ちになるんです。 それで大手の飲食の会社では、大体そのくらいでお金がまわるように計算して、「じゃあ次は○○海産かな」とか「○○農場とかどうかな」とかって感じで、お店を潰しては新しくしてっていうのを繰り返すんですね。 僕たちのような小さいお店は、資金的な余裕もないし、例えばフレンチでしか修行をしていないので、突然和食をやろうなんてことも出来なくて、まああまり潰して新しいお店を、なんてことは出来ません。 それでまあ、ちょっとづつ「売り上げ」が減って、「まあここらで閉めようか」って
ファッション業界で話題の八木さまに迫る！ | Numero TOKYO
Fashion / Post ファッション業界で話題の八木さまに迫る！ 2017.12.2up 国内外のファッションイベントで、視線を奪っている話題の人物、八木さまこと、八木恵利子さんとは一体何者？（「ヌメロ・トウキョウ」2016年9月号掲載） ジャケット／Marc Jacobs 中に着たシャツ／Gucci ビスチェ、タイツ、シューズ、バッグ、スカートにしたヒョウ柄のトップ／すべてDolce&Gabbana ネックレス／Lanvin（すべて私物） さまざまなメゾンの顧客である八木恵利子さん、60歳（2016年取材時）。すらりとした美しい脚をウォルフォードのタイツで包み、足元を日本では入手困難なショウピースのシューズで飾る。独自のバランス感覚で、色×色、柄×柄、さまざまなアイテムを盛り重ねたファッション。そこには、彼女が生きてきた色濃く、複雑な半生が反映されている。“More is More
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
Payment Request API の仕組み | Articles | web.dev
Payment Request API の仕組み コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Payment Request API ユーザーが販売者のウェブサイトで購入しようとすると、支払い情報と、必要に応じて配送設定などの情報の提供をサイトからユーザーに求める必要があります。Payment Request API（PR API）を使用すると、この操作を簡単かつ迅速に行うことができます。 基本構造 PaymentRequest オブジェクトの作成には、お支払い方法とお支払いの詳細という 2 つのパラメータが必要です。また、3 つ目のお支払い方法のパラメータは省略可能です。次のような基本的なリクエストを作成できます。 const request = new PaymentRequest(paymentMethods, paymentDetails);
プロジェクトをリードする技術 - kakakakakku blog
今日，社内勉強会で話す機会があり，過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした．今回は参加者がエンジニアだけじゃなく，ビジネスチームのメンバーもいたため，できる限り，技術的な用語を使わないようにした．質疑応答とディスカッションもあり，1時間非常にワクワクした時間だった． 関連する領域 僕がプロジェクトをリードするときに意識しているのは，スクラムなど特定のプラクティスに依存しすぎないことで，チームの特性によって，関連する様々な領域からプラクティスを集めている．ザッと挙げるだけでも，こんなにたくさんある． チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ！プレイングマネージャーとして頑張っ
初期スタートアップにおける社内文化の在るべき形とは - machio Development Diary
はじめに この記事は6人の小さなチームのマネジメントを3ヶ月齧っただけの僕が、それでも外部のメンターさん方に猛烈に相談に乗っていただいたりしながら 社内文化 について試行錯誤した道のりについて綴っています。拙文ですが温かく見守ってくださると幸いです。 背景 簡単に背景を共有させていただきたいと思います。 僕が3ヶ月間エンジニアのマネージャーを経験したこと 僕が所属している 株式会社Flatt のエンジニアチームは 12月まで 1月以降 実働人数 3人 2倍の6人に 社長の関わり方 手も動かしつつマネジメント 現場を離れて社長業に専念 （マネジメント層が不在） というように 2017年 => 2018年 という年の変わり目を境に大きく環境が変わりました。 そこで純エンジニアポジションでは1番の古株だった（それが理由かはわかりませんが）僕がエンジニアのマネージャーに抜擢され、この3ヶ月間 6人
JikkanKudo2016_BPStudy
BPStudy#105 http://bpstudy.connpass.com/event/29494/
フロントエンドエンジニアのための動画ストリーミング技術基礎
動画はデータ容量が大きい 画像と違い、動画コンテンツはデータ容量がとても大きいため、データをダウンロードして再生するまでに待ち時間が発生します。 動画のデータ容量が大きい理由はとても単純で、動画は画像データが集合したものだからです。静止画像を人間の目が滑らかに感じられる速さで切り替えて表示することで絵を動かすという表現を実現しています（よくパラパラマンガに例えられますが、そんな感じです）。この人間の目が滑らかに感じる速さというのが 1 秒間に 30 枚だったり 24 枚を切り替えることになります。29.97 (≒30) fps とか 24 fps とかの数字を耳にしたことがあるかと思いますが、24 fps の場合は 1 秒間（s）の間（p）に 24 フレーム（f）を切り替えることを意味します。 データを全て自分の端末にダウンロードしてから再生しようとすると、かなり長い待ち時間が発生してしま
トップレベルのコンピュータエンジニアなら普段からチェックして当然の技術系メディアN選 - kuenishi's blog
〜〜が知っておくべきサイト20選とか、エンジニアなら今すぐフォローすべき有名人とか、いつも釣られてみにいくと全く興味なかったり拍子抜けしたりするわけだが、こういうのが並んでいたらあまりの格の違いに絶望してしまうだろうというものを適当に並べてみた。私が見ているわけではなくて、こうありたいと思っている私の願望である。どちらかというとインフラ系とか基盤系のものに偏っているが、あくまで私が興味ある一連の例だと思ってください。「これが入ってない！」というクレームは受け付けますので、是非教えてください。一緒に成層圏まで意識を高めましょう。 情報サイト、有名ブログ Software Engineering Radio : IEEEが主催しているソフトウェアエンジニア向けのPodCast。データベースからフロントエンド、暗号、ハードウェア、マイクロサービス、などなどとにかく多様なジャンルの最新のトピックの
マイクロサービスで必要になるかなぁって思って僕がOAuth2とOpenID Connectをなんとなく分かるようになるまでの物語 - Mitsuyuki.Shiiba
プライベートの勉強は気が向くままにふらふらと。梅田の地下街を歩いてる感じで！（←つまり迷ってる） 元々は、Pivotal Japanさんの、この「今日から君もヒーローだ！」的なタイトルに惹かれてJava(Spring Cloud)でマイクロサービス作るぞーって進めてみたのであった。が、早速その2の「認可サーバーを立ち上げよう！」で「あー、これ知らない。分かんない。もう寝たい。」となってしまったのだった。 そんな僕が「なんとなく分かった！」になるまでの物語。・・・になるはず（ここを書いてる今はまだ分かってない）。 たぶん1ヶ月したら何を読んだか忘れてると思うので記録しとくことにした。 github.com ゴール OAuth 2.0って聞いたことあるけど、よく知らない。この辺、マイクロサービスの認証・認可部分で必要そうだなーって思うので、OpenID 2.0とOpenID Connectも含
20代エンジニアの成長を阻む7つのパターン（まとめ記事） - Qiita
10分で生産的なミーティングができるWebサービス「minmeeting」を開発している伊勢川です。 本日は、これまで連載で紹介してきた2年目〜5年目エンジニアが陥りがちな症状と予防を要約して、まとめ記事を書きました。 網羅的にパターンを洗い出した訳ではなく、たまにそういうやつおるなという「おるおるネタ」の7選です。 若手エンジニアの皆さんは、ぜひこのようなくだらない失敗を繰り返すことなく、よりよい20代を過ごしていただければと思います。 Google依存症 Googleを調べれば何でもでてくる便利な時代が生んだ症状です。 症例 エラーログをGoogleで調べて出てこなかったら、それは解決方法がないと思ってしまう。 新しいことをやろうとして、Googleに実現方法が書いてなかったら実現不可能と思ってしまう。 予防法 Googleは日本語が苦手なので英語で聞く。 Googleで見つからない解
タベリー | カスタマーファネルと向き合う – Yamotty – Medium
年末年始に、タベリーというプロダクトをする過程をブログに記載したり、CAREER HACKさんに取材していただいたりした。 ところが、プロダクトは「発明前」より、その価値を測定・分析し、磨き込む「発明後」の期間のほうがずっと長い。 プロダクトのタイプごとに、いわゆる「グロースのための方法論」はMediumなどを少し漁ると多くの事例と出会うことができる。たとえばGreylock Partnersや、著名なProduct Managerが公開している記事は秀逸なものが多い。 他方で、 「他国で成功したプロダクトをローカライズするプロダクト」や、「プロダクト自体ではなくそこに乗るコンテンツに差別化要因があるプロダクト」ではなく、「新しい発明」を目指す場合、汎用化された事例を元に意思決定するのは難しいと感じる。 タベリーは「意思決定の新しいフォーマット」のチャレンジでもあるため、どういった切り口で
Rails Developers Meetup 2018 で「正しく失敗しつつ進むプロダクト開発」という話をしてきました - Kaizen Platform 開発者ブログ
Application Engineer の ryopeko です。 3/24 と 25 に開催された Rails Developers Meetup 2018 で登壇してきました。 自分のセッションは 3/25 14:50~ の回で、「正しく失敗しつつ進むプロダクト開発」というテーマでお話ししました。 当日は2トラックのセッションだったにも関わらずたくさんの方に見に来てもらえました。ありがとうございました。 今回のお話しは Kaizen Platform でのものづくりのプロセスの変化ということをメインにしてみました。 以前から勉強会やカンファレンスで会う人に「Kaizen Platform って名前は知っているけどどんなことやっているのかよくわからない」とか「なんかすごそうで怖い」とか言われてきたので、なるべく普段の様子を伝えたいと思いました。 Kaizen Platform は創業5
The 3 Tenets of Service Objects in Ruby on Rails | HackerNoon
Too Long; Didn't ReadService Objects are becoming a staple in the toolbelt to slim down both Controllers and Models. Welcome to the world of fat services [folder]! A quick refresher to those who may not know what a Service Object… Service Objects are becoming a staple in the toolbelt to slim down both Controllers and Models. Welcome to the world of fat services [folder]! A quick refresher to those
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Material Components
Istioと共にマイクロサービスに立ち向かえ!
Kubernetesに入門したい
