Fringe81株式会社は2021年10月1日より、Unipos株式会社として生まれ変わりました。 コーポレートミッションを「感情報酬を社会基盤に」と新たにし、ピアボーナスをさらに発展させ、感情報酬を社会実装して社会の基盤とすることを最上位の目標として掲げ、邁進して参ります。 5秒で自動的に切り替わります。切り替わらない場合は以下のボタンをクリックしてください。 Unipos株式会社サイトへ
本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う(詳しくは検索してきて!) sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった
By Robert Scoble フリーフードや24時間使用可能なジム、無料ランドリーなどさまざまな福利厚生がそろった夢の企業「Google」は、求人サイトGlassdoorにより作成された「給与&福利厚生が優れた企業トップ25」でも堂々のトップレートをたたき出しています。Googleではエンジニアの意見が尊重され、平均年収は約12万ドル(約1450万円)にもなるといわれていますが、そんなGoogleのエンジニアになるために必要なスキル11個をBusiness Insider Indiaがまとめています。 11 skills you need to master to land a $100,000 engineering job at Google | Business Insider India http://www.businessinsider.in/11-skills-you-n
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。Read less
Photo by Petras Gagilas こんにちは。谷口です。 来年度にITエンジニアとして新卒入社をされる皆さんは、IT系のニュースや情報の収集はどうやってしていますか? 先日弊社が開催いたしました、学生の方向けの勉強会でも「就活中や入社前に見ておくと役立つサイトはありますか?」「入社後はどういった情報サイトで情報収集や勉強をすると良いですか?」といった質問が多く寄せられました。 paizaでpizzaを食べながらもぐもぐ勉強会レポート - paiza開発日誌 そこで今回は、4月にエンジニアとして新卒入社をされる方々が、デキるエンジニアになるためにチェックすべきIT系情報ポータルサイトを9件ご紹介いたします。日々の情報収集にお役立ていただければと思います。 ■IT系情報サイトまとめサイト9選 ◆1.ITmedia http://www.itmedia.co.jp/ ITmedia
はじめに 日本のIT業界では、技術職求人に対して、ちゃんと専門教育を受けていない(独学で身につけたわけでもない)人の応募の割合がとても高く、絶大なる不幸を生み出しているのが現状です。 これから社会人になる就活生の皆さんには、できれば不幸な人生ではなく幸せな人生を歩める選択をしてほしいとの願いから、このエントリーを書きました。 注意:ITエンジニアとして就活をしてプログラマー的な仕事が主な業務になる人が多いと思うので、この記事に出てくるITエンジニアという言葉は、プログラマーのことだと思って読んでいただけると幸いです。広い括りの題名をつけてしまってすみませんが、インフラ/ネットワークエンジニアやメーカーのエンジニアの話は出てきませんので、ご容赦ください。 目次 背景 プログラミング言語を覚えよう データベースの使い方を覚えよう オリジナル作品を作ろう(ここが一番大事) IT系の勉強会に参加し
(あんま多くないみたいだから多分すぐ身バレしそうだけど書く) エンジニアの面接で実際にコードを書かせる会社が最近は多いみたいだね。でもウチでは特に面接で書かせない。というか今まで書いてきた、関わってきたコードなんて書類で大体分かるでしょ? それよりも、ウチではコードレビューをさせてる。 選考用にわざと少し突っ込みドコロの多いコード(30〜50行程度のコードを3〜4ファイル)を渡して、もちろんファイル構成自体へのレビューも含めて、どんな意見をその人が出せるかを問う。 レビュー用のコードは複数言語用意してて、一番得意な言語を選んでもらってる。 時間は1時間。資料と赤ペン、そしてネットに繫がったパソコンを渡して、いくらでもググってもらって構わない環境でレビューを紙に赤して貰う。 「コードレビュー」ってものに対しての認識だとか、コードを管理するための能力もある程度分かるし、すごく良い選考制度だと思
私が面接官を手伝っていた時、印象に残った出来事がある。 その日は午前中に中途採用の面接があった。面接を受けにきた応募者は31歳、年収450万のエンジニアである。彼は過去に2回、転職をしており、もし我々が採用を行えば4社目、ということになる。 彼のスキルは特に低くもなく、高くもなくといったところで、年齢相応のスキルと言った感じだ。 本音を言えば、私が面接を手伝っていた会社は30前後のエンジニアが欲しかったので、彼の応募は有り難いものであった。 面接が始まり、役員の一人が質問をする。 「なぜ、転職を考えたのですか?」 通常であれば、ここで返ってくる回答は、「上流工程をやりたかったので…」であったり、「お客さんと直接話せる仕事がしたかった…」など、当り障りのない回答がほとんどだ。 しかし、彼は違った。開口一番、 「はい。もっと給料が欲しかったからです」 と言ったのだ。 通常であれば面接の際に志望
改訂:2014/10/20 備忘録としてまとめていきます。 今まで集めていた情報まとめていきます。 すでに読んだやつも今これから読んでこうってやつもまとめにまとめちゃいまっせ。 アウトプットも大事だけど、自分より先輩の方がアウトプットし続けて頑張って得た知見をあっという間にインプットできる"本"という形での学習も超大事なのです。 エンジニアとしての心得みたいな本 ハッカーと画家 コンピュータ時代の創造者たち 作者: ポールグレアム,Paul Graham,川合史朗出版社/メーカー: オーム社発売日: 2005/01メディア: 単行本購入: 109人 クリック: 4,884回この商品を含むブログ (594件) を見る YCombinatorの共同設立者の彼の本。 CODE COMPLETE 第2版 上 作者: スティーブマコネル,Steve McConnell,クイープ出版社/メーカー: 日
「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン
ネタ元: 「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件 | 新田章太の「エンジニアをつくる」ブログ 話の発端は、 俺がDMTCについて知ってること,またそれに対する所感 - 職質アンチパターン がFacebookで話題になっていて、やばいなぁと思っていたら主催者もやばかったみたいな話。 内容自体ただヤバイんだけど、その中でも明確にツッコミを入れておきたい部分があった。 僕らの強みはDMTCを通じて、沢山のお客様とのつながりがあること このつながりを活かして、 国内外のIT企業で働くエンジニアのスキルを定量化しよう というひとつのテーマにいきつきました。 http://maximum80.me/archives/821 この部分についてFacebookで俺はエンジニアをバカにしてるって書いたけど、もうちょっと具体的に落としこもうと思った次第です。 ものさし
最近ずっと仕様書を書いているのだが、なかなかうまく書けない。できるだけ次はうまく書けるようにメモをしておこう。 設計書の種類と目的 開発工程の共通知識 各設計書の説明に移る前に、ここではウォーターフォール型の開発における開発工程についての概要を記載する。 ウォーターフォール型開発の概要 開発工程についての基本的な説明はwikipediaを参照 ソフトウェア開発工程 - Wikipedia 最もよく知られた従来型の開発工程モデルはウォーターフォール・モデルである。このモデルでは、開発者は上述の工程(局面、フェーズ)を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し(単体テスト→システムテストの順)、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土
Photo by Joi 今回のpaiza開発日誌は片山がお送りします。 今後も技術(開発)を中心にエンジニアとしてのキャリアを歩んでいきたいなと考えている方向けに最近騒がれているフルスタックエンジニアとは何か、という事と、何故今後フルスタックエンジニアしか生き残っていけないのか?という事について書いてみました。 ■最近よく見かける【フルスタックエンジニア】とは何か? まずStackって何だろう?、というところで海外の記事などを読むと"LAMP stack"という言葉が良く出てきます。LAMPの場合、OSはLinux、WebサーバはApache、データベースはMySQL、プログラミング言語はPHP(もしくはPerl、Python)という形で組み合わせたものの事を言います。つまりOS、Webサーバ、DB、プログラミング言語の組み合わせ≒積み重ね、なのでStackという事のようです。こういった
春になって暖かくなると、ついつい意識が高ぶってしまいますね。 今回はあくまで個人的な、エンジニアの評価基準とキャリアパスについての私見を、どちらかというと新人の方向けに垂れ流してみたいと思います。 はじめに 新人の方々は今頃は、研修に追われていたり、それが終わっても配属先で揉みくちゃにされる日々が待っているでしょう。中には既に後ろ向きな思考になっている人もいるかもしれませんが、そういう人には今回どうでもよい話で、前向きな人がそのエネルギーをエンジニアとしての成長に無駄なくつぎ込むために、若いうちにあまり考えないけど、考えておいた方がよい話をします。 ITエンジニアとして始動すると、目の前に与えられた仕事だけでも楽しいのに(その過程で苦しむのは別として)、さらにその先にIT知識が広く深く待ち受けていて、こんなことをやりたいんだ、全部マスターしてやるんだと意気込むかもしれません。そして、目の前
昔から「エンジニアは営業が苦手」とか「エンジニアはデザインが苦手」とか、あるいは「エンジニアはコミュニケーションが苦手」というような言われ方が嫌いだった。 実際、営業が苦手なエンジニアというのはいると思う。でもそれはエンジニアだから苦手なのではなくて、単にその人が営業が苦手なだけだ。同じように、デザインに関してもコミュニケーションに関してもそうだ。 おおまかにそういう傾向があるということまでは否定はしない。例えばプログラミングのカンファレンスに行くとそこでは男性率が非常に高いし、全体としては、まあなんというかリア充とはちょっと違う雰囲気を醸し出している・・・というようなところがあってそれは誰もが感じることだろう。集団を集めて一般化してみるとそういう何かしらの傾向が現れる、ということまでは否定はしない。 でもやっぱり、その「エンジニアだから○○」という型にはめたような話を自分自身にあてがって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く