仕事を教える人へ https://t.co/V8xmDWXGtT
仕事を教える人へ https://t.co/V8xmDWXGtT
「ようこそ 魔境 SIerへ!」 はじめに この記事は、SIer(Systems Integrator)に入ったシステム開発未経験者の新人さんたちへ送る、研修では教えてくれないノウハウ集です。 実際、弊社の長い研修では実務に使えそうなことをあまり教えてくれませんし、ノウハウは現場の人の頭にしかない状態なので、新人さんは暗中模索で仕事を覚えていくことになります。 それも非効率なので、実際に私が2年半1で失敗したこと、やってきてよかったこと(ノウハウ)を体系化したので共有します。 新人さんは、これを参考として、使えるところだけ今後の業務に持っていってください。 (本当はガッツリ社内向けに書いたものなので、一部汎用的でない表現がありますがご了承ください。) 目次 業務面 技術面 プライベート面 の三本柱でお送りします。 対象読者 SIerの1,2年目相当であり、学生時代に契約のあるシステム開発を
Transcript 30代から始めるwebフロントエンド入門 コネヒトマルシェ #2〜webフロントエンド市〜 @itosho 1 ▪ 自己紹介 ・伊藤 翔 / @itosho ・所属:コネヒト株式会社 / Supership株式会社 ・野球とアイドルが好きです。 ・最近のオススメ:sora tob sakana 先日メジャーデビュー ▪ 自己紹介 ・伊藤 翔 / @itosho ・所属:コネヒト株式会社 / Supership株式会社 ・野球とアイドルが好きです。 ・最近のオススメ:sora tob sakana 先日メジャーデビュー ・主にサーバーサイドエンジニアをやっています。 ・よく書く言語:PHP / Ruby / Golang _人人人人人人人人人人人人人人_ > サーバーサイドエンジニア <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ 4 ▪ 今日話すこと
bonfire frontendで発表した今後のフロントエンドの話です。
Youtubeの要約です。 先日すごく感銘を受けた動画を見ましたので、シェアさせてください。 もっと短く要約しようと思ったのですが、ほとんど和訳になってました。ところどころ省略しているところもありますので、全文訳で無いことは注意です。 3 top qualities for a Software Engineer to be successful Techlead Google Youtube Patrick Shyu 【導入部分】 手を早く動かす事はとても大事。何も意味がなくても、キーボードを早く叩いたり、マウスを動かしたり、「早く動く真似事」をするだけでも体が早く動く事に慣れるので、普段からやっておくと良い。 1 【インパクト】 エンジニアにとって重要なのは、単にとても多くのバグを無くすだけでも、リファクタリングするだけでも、フレームワークを作るだけではないです。 重要なのはポジティブ
connpass.com メルカリには海外に勉強のために行ける制度があるらしい。それを利用して海外に行ってきた人たちが、国外のトレンドを紹介するイベントをやっていたので行ってきた。 ちなみにメルカリの海外への支援制度は以下のような形であり、かなり好待遇な制度であることがわかると思う。 好きなときに行きたいところに行ける 業務扱い 通訳や旅費などをほとんど支援してくれる 社外の人も一緒に行ける 海外のエンジニア系のニュースは見ていたつもりだけれど、やはり現地に実際に行ってきた人の話を直接聞くと衝撃を受けるものが多かった。 今回のイベントでは、 上海 エストニア・フィンランド シンガポール ニューヨーク という四カ国にわけて紹介された。それぞれ聞いた内容を箇条書きにしていく。 上海 上海に行った理由 ・上海のすすみっぷりがヤバイと社内で話題になっている ・シェアバイクサービス:mobike,
新しい技術が出てきたとき、大多数の若い人よりも圧倒的にスピーディーに使いこなすおっさんは珍しくない。 新技術を習得する能力は、年齢よりも、「スキルを獲得するために必要なスキル」、すなわち「メタスキル」に大きく依存するからだ。 たとえば、ある開発ツールを導入すべきかどうか若い人に相談されたので、「まず、ドキュメントを読もう」と言ったら、「ドキュメントを読んでもよくわからなくて。。」と言う。ググったらすぐに公式サイトの至れり尽くせりのドキュメントが出てきたので、「これ読めばいいじゃん」と言ったら、こんなに大量の英語のドキュメントを読むのは無理だと言う。 あるいは、AIを導入するという話になったとき、「AIがよく分からないので教えて欲しい」と言ってきた若い人に、良質の入門書を勧めたら、数式が分からないので読めないのだという。数式の読み方を教えてみたら、数式以前に、そこで使われている数学概念自体を
ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら
みなさんこんにちは。@ryuzeeです。 2016年9月16日に行われたDevelopers Summit 関西で表題のテーマで登壇してきましたので資料を公開します。 カイゼンについては1日のトレーニングコース(バリューストリームマップ作成含む)を[@haradakiro](https://twitter.com/haradakiro)と提供していますのでご興味のある方は[ご連絡](https://www.ryuzee.com/contact.php)ください。 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。 詳細はこちら
こんにちは。技術コンサルの高松と申します。 最近、矢野さんのトイレの空き状況の見える化システムが公開されましたね。 「自分もおもろい社内ネタを出したい!」と思ったので、アップします。 あ、IT要素ゼロなんで、気楽に見てください。 概要 紹介したいのは、私が運営している「オフィスコンビニシステム」です。 「オフィスでお菓子が100円で購入できる!」は某サービスは同じですが、それを社員自身が運営するというものです。 2014年4月から運営を始め、もう2年になります。(いつのまにか、高松商店とご愛顧頂くようになりました) 手前みそですが、社内の利便性向上に貢献してるんじゃないかなと思っています。 利用方法も某サービスと同じです。 お好きなお菓子1つとって、貯金箱に100円入れればOKです。 カエルの貯金箱は、某サービスを連想しますね。 以下のような品物が、社内のリフレッシュコーナーで購入できます
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
最近お手伝いしている所のサービスについて色々ディスカッションする機会が増えて、時折議論が噛み合わないなぁと感じることがあったり、別件で、違う会社の人の話を聞いてても、些細な所でちょっとした違和感を感じるケースがあったりしました。 なんでそういう違和感を感じるのかイマイチ掴めてなかったのですが、自分は、常にサービスという言葉を常に意識して言葉に出してるのに対して、相手の方はプロダクトという言葉をおそらく無意識に使ってるからなのかなとなんとなく感じました。 ここでいうサービスとプロダクトの言葉の意味合い 言葉の定義としては、自分の中ではこんな意味で考えてます。 プロダクト思考 どういう機能がいいのかをまず考える サービス思考 誰が使うものなかを考える アプリとかサービスを出したらおしまいではないのでその後どうやったら使い続けてもらうのかを考える 使い続けてもらうからには当然売上も立たないといけ
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す・・・というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
要するにデータセンターの「原価計算」です。いろいろこのあたりに関わっています。複雑な計算ロジックと大量のデータを扱う必要があるので、大規模並列計算の適用が必須になり、結果として当方の出番になった、という状態。尚、実行基盤にHadoop(MapR)を利用しています。(一応予定ではSparkに移行するつもりで、開発も始まっています。) さて、いろいろやっていて思うところがあるので、現時点での考え方をまとめておきます。機微な部分はNDAになるので書きませんし、以下は自分の「個人的な」意見であり、特定のサービサーの話をしているわけではありません。基本的にInteropで公にしゃべった話のまとめです。 ■現状認識 現在、国内DCはほぼ乱立状態に近いと思われます。ここへ来て春先のAWSの値下げのインパクトもありました。今後は、より競争的なマーケットになるでしょう。退場する企業やM&Aも活発化していくで
「画面」のデザインは、エンドユーザーから見た「プロダクト」との唯一の接点。超大事。 そんな画面のデザインにまつわる、エンジニアが「いじる」ときに気をつけると、もしかしたら面倒が減って争いが減ってみんなが幸せになれるんじゃないかなあ、とか、そもそもの設計上で考慮できると、もしかしたら使う人たちが幸せになれるんじゃないかなあ、というポイントを、思い付きで書いていくので、あとは誰か整理してほしい的な投げやり感あふれるアレコレ。デザインとコーディングの話を混ぜて書いてます。 空白の理由を考える編 その1. 空白にまつわる認識の相違 例えば、Tumblrのダッシュボード。右肩のメニューの隅までちゃんとレイアウトされてるなーって感じがします。 でも、もしあなたが「空白を理解しないエンジニア」だった場合、こんな感じにコーディングしてしまうかもしれません。 (※画像はイメージです) 「なーんか、素人感があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く