LAPRASのソフトウェアエンジニア向けスキルチェック課題を公開しました - LAPRAS Tech Blog
こんにちは、LAPRAS CTOの @rocky_manobi です。 タイトルの通り、LAPRASのソフトウェアエンジニア職の選考課題を公開しましたので、その詳細や心についてこの場を借りて紹介します。 公開した選考課題はコチラ GitHub - lapras-inc/exam-swe-template: SWE Backend, Frontend ポジション選考課題のテンプレートリポジトリ SWE Backend, Frontend ポジション選考課題のテンプレートリポジトリ. Contribute to lapras-inc/exam-swe-template development by creating an account on GitHub. github.com どうして公開したのか主に以下を目的としています。 応募の心理的なハードルを下げる会社を評価するための材料を提供する
住んでいる場所はもう言い訳にならない。地方から発信を続ける元SIエンジニアを駆り立てた「強烈な劣等感」 - Findy Engineer Lab
中道一志（@ici_mici）と申します。この記事が公開されるころには、島根県の西端部にある益田市での暮らしが始まっています。水と木々がきれいな、少しばかり人のいない街です。 広島から島根への移住。義実家での子育てのため、私はこれまで勤めていたSI企業を辞め、Webサービスを提供する福岡の企業で2022年6月からフルリモートの勤務を選択しました。 ニューノーマルという言葉が生み出されて数年、ソフトウェアエンジニアは自由な生き方を選択できる職業の筆頭になっています。この記事では、地方都市広島から日本全国のコミュニティに登壇して、全国規模のカンファレンスを主催し、そして転職と移住を決断した私の経験をお話します。 焦燥感と憧れに突き動かされて一歩を踏み出す 誰でも、何でも、どこからでも、学んで伝えることができる コロナ禍の大きな3つの選択 ─ 主催・登壇・誕生 ソフトウェアエンジニアが働き方を選
面白い課題を解決したいソフトウェアエンジニアへ ── 複数の専門性が交わるところで「今できないこと」をやる - Findy Engineer Lab
はじめまして、田籠聡（@tagomoris）です。現在はフリーランスのソフトウェアエンジニアとしていくつかの会社で技術顧問をしつつ、個人的なプロジェクトの開発をしたりしています。これまでのキャリアとしてはISPやSIerで働いたのち、livedoor（およびその後のLINE）や、Treasure Dataといった会社で働いてきました。また、みなさんがご存じかもしれないものだと、ISUCONというイベントを始めたり、データ分析基盤関連の技術やFluentdをはじめとしたOSSプロダクトの開発に関わったりしています。 自分のキャリアを振り返ると、これまでいろいろと面白いプロダクトやサービスに関われてきました。一方で、自分にとって面白いプロダクト・面白い開発とは何かということが、経験を積むにつれて変化してきたとも思います。この記事では、何を面白いと思うか？ どうやって面白いものに関わり続けていく
エンジニアが LayerX へ人事として入社しました｜serima
昨日から LayerX に人事として入社した serima です！ いままで 10 年ほどサーバサイド・インフラを中心にソフトウェアエンジニアや Engineering Manager として活動してきたので、個人的には割と大きなジョブチェンジかなと思っています。 LayerX では、まずはソフトウェアエンジニアの採用活動に軸足を置きますが、事業成長に必要なことはなんでもやりたいと思っています！ 自己紹介と転職のきっかけかなりサマリですが、高専卒 → 大学編入＆中退 → 位置情報系サービスで学生起業 → ソーシャルゲーム開発・運用 → エンタメコンテンツ、メディアの開発・運用とキャリアを積んできました。 「積んできました」というと聞こえはいいかもしれませんが、改めて振り返ると「球拾いをしてきた人生だった」感があります。 小学生の頃にサッカーをやっていましたが、好んでディフェンダーになりたが
Why Programming is Easy but Software Engineering is Hard
Beginners who want to get into the software field often get programming and software engineering mixed up. These are not the same thing. Programming is a part of software engineering. Software engineering on the other hand, encompasses so much more than programming. Software engineering is the process of starting with a problem, designing a way to solve that problem, and then delivering a software
ソフトウェアエンジニアと技術力 / developer-lifework
Hamee様 開発合宿 2021年（前半戦）の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://soudai.hatenablog.com/entry/2017/06/03/183508 - https://soudai.hatenablog.com/entry/2018/02/09/131638 - https://speakerdeck.com/twada/worse-is-better-understanding-the-spiral-of-technologies-20
41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々
最初にお断りしておくと、このエントリは驚くほど僕固有の私的な話に終止するので、他の人の参考にはならないでしょう。 ICというのはIndividual Contributorの略で、最近だとHashiCorp創業者のあのMitchell Hashimoto氏が、HashiCorp社内でICになるというのも話題になりました。日本でも、こにふぁーさんがそういう動きをしていたりして、ちょいちょい聞くようになってきた印象です。 今回の僕の転職は、言ってしまえば、自分が培ってきたソフトウェアエンジニアとしてのスキルを活かして世界の舞台で戦いたいという気持ちを抑えきれなかった、という幼稚な理由です。自分が求めているものがLaunchableにはあるように感じて入社しました。 振り返ってみると、最近の自分の転職における決め手は「自分を一番必要としてくれるところ」という側面が強かったと感じています。その結果
クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)
すでに何人かの人がクリーンアーキテクチャなんてないよ、って話はしていてイマサラだと思うんですが。 あえてブログの記事に残そうかなと思って書いてみます。 最近、改めてクリーンアーキテクチャ本を読んだり、原文を読んだり、 ここ数ヶ月ツイート色々な人のを観測したり社内で話したりしていて 考えがまとまってきたので、自分の言葉で整理してみたくなった。 「へー、クリーンアーキテクチャっていうソフトウェアアーキテクチャがあるんだー」という微妙な誤解？をちょっとでも減らす一助になればという感じです。あと、本の読み進め方のヒントにもなるかも 先に結論 クリーンアーキテクチャというのはアンクルボブの書いた本。 ソフトウェアアーキテクチャのことではない。 the クリーンアーキテクチャというブログ記事はただのソフトウェアアーキテクチャの例(そして本の一部分)だが、独り歩きしている クリーンアーキテクチャというソ
ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい 2 - 覚書
↓の続きです。 satoru-takeuchi.hatenablog.com 何をするにも知名度の有無によって注目度は変わります。極端な話をすると、誰かがものすごいことを成し遂げたとしても、誰とも接点が無い人がやれば誰にも知られず、すでに名のある人がやれば注目されます。なので知名度があればそれだけでいいか…というとそうではないです。 知名度の高まりかたにはいろいろと種類があります。そのうち一つは名声を博することです。名声を博するには技術者としてのスキルや地道な実績の積み重ね、場合によっては自己プロデュース能力が必要です。とてつもなく凄いが目立つのを嫌う人もいるので一概に知名度があればいいというものではないですが、その話はここでは置いておきます。 その一方で、人から眉をひそめられるようなことをすると悪名がとどろきます。これには別に技術者としてのスキルは必要ないので名声を博するよりも簡単です。
プログラマーがドキュメントを書かない理由
この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである
「リリース疲れ」を解消するために「リリースレゴ」をやってみた - エス・エム・エス エンジニア テックブログ
介護や医療、ヘルスケアなどの領域で、高齢社会に適した情報インフラを提供している株式会社エス・エム・エスの西村直人（@nawoto）です。私は2005年からソフトウェア開発においてアジャイル開発を実践しており、現在はアジャイル開発の考え方を軸にチーム開発の支援などを行っています。 エンジニア組織ではリリースを頻繁にできることが望まれますが、リリースすることに疲れたりしませんか？僕たちは「リリース疲れ」と呼んでいますが、疲れが溜まるようにどんどんリリースが辛いものに感じてきます。エンジニア以外に言ってもあまり理解してもらえませんが……。 そんな悩みを解決するべく、エス・エム・エスの開発チームで行ったのは、レゴを組み立てること。え、なんでレゴ？そんな「リリースレゴ」という取り組みについてご紹介します。 プロダクト開発を継続すると起こる「リリース疲れ」 事業は長く継続していくように構築されているも
CLOG
現在 M+ FONTS は Google の支援をいただき、Glyphs を使用してデザイン修正の作業をおこない、GitHub にてその成果物を公開しています。しかし自分がここまで M+ FONTS の制作を続けることができたのは、開発当初の、多くのプログラマーの方によるご協力があったからです。自分のデザインした文字がオリジナルのスクリプトによってフォントファイルにまとめられ、コンピューター画面に表示されるさまは、まるで魔法をみているかのような素晴らしい経験でした。 また 1988 年にはじめての Macintosh を購入してからフリーソフトウェアの文化に感動し、いわゆる Unix 系の OS を使い始めてからも、さらに多くのフリーソフトウェアの恩恵にあずかりました。M+ FONTS では当初から、少しでもプログラマーの方々のお役に立つことができればと固定幅フォントを用意していましたが、
自分が一番強くなくてもいい。コミュニティで理解した強みを生かして、ピープルマネジメントをしない技術の責任者になった - Findy Engineer Lab
初めまして。丸山しんぺい（@shinpei0213）です。Classi株式会社で、VPoT（Vice President of Technology）という役職に就いています。技術部門の責任者として、Classiという会社がソフトウェアの力で教育をよりよくしていけるようなあれこれについて、技術の視点からグランドデザインを描き、そのグランドデザインを達成することに責務を負っています。 今回、キャリアとその選択について書く機会をいただいたため、あらためて自分のキャリアを振り返ってみると「スペシャリストとして成長した先に、技術の責任者があった」となりそうです。それが正しいとも、誰でも参考になるとも思っていませんが、それでもソフトウェア・エンジニアは比較的新しい職種であり、再現性の高いキャリアパスもまだまだ整備されていない世界だからこそ、誰かが振り返ったキャリアが他の誰かのヒントになることがあるか
競技プログラミング、ソフトウェア・エンジニア、コミュニティ
なんか言及もされたのでアンサー的に書いてみたけど、アンサーには大してなってないな? ってやつです。一部で言及された、競技プログラミング (競プロ) 関係の話。 その前に、「プログラミングの競技」っていろいろあります。 短時間で問題に解答していく型 (ICPC / 情報オリンピック / AtCoder Regular / TopCoder とか)最適解が容易に求まらない問題のスコアを競う型 (SuperCon / AtCoder Heuristic / ISUCON / ゴルフ / ICFP Programming Contest の一部とか)対戦型 (ICFP Programming Contest の一部とか、最近のはあんまり知らないですが RoboCode / Imagine Cup とか)謎解き型 (ICFP Programming Contest で何回かありましたね。 UMIX
Tao of React - Software Design, Architecture & Best Practices
Tao of React - Software Design, Architecture & Best PracticesJanuary 18, 2021 • 25 minute read I’ve been working with React since 2016 and still there isn’t a single best practice when it comes to application structure and design. While there are best practices on the micro level, most teams build their own “thing” when it comes to architecture. Of course, there isn’t a universal best practice tha
[フロントエンド] うわっ…Componentの凝集度、低すぎ？ - Qiita
[追記 2021/4/26] Storybookを導入して凝集度を向上させる記事を書きました。 0. はじめに 有名OSSのコミッターから、コピペで動かすマンまで、彼らは等しくプログラマと呼ばれます。10xプログラマという言葉があるように、同じプログラマでもその生産性には天地ほどの開きがあります。 プログラマの生産性は、1968年のSackmanらの研究以来、ソフトウェア工学でも熱い研究テーマの一つですが、未だにプログラマの生産性を測る指標は確立されていません。 一方、広木大地氏は自著「エンジニアリング組織論への招待」で、エンジニアリングを不確実性を削減する行為と定義しました。プログラミング能力を測る重要な尺度として、モジュールの凝集度があります。高い凝集度で設計しコーディングされたモジュールは、見通しがよく、再利用可能で、バグが少ない…つまり不確実性が少ない状態と言えるでしょう。 システ
![[フロントエンド] うわっ…Componentの凝集度、低すぎ？ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b1fb1663f9c42a396db97571055b22a8887df2bb/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgzJTk1JUUzJTgzJUFEJUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgzJTg5JTVEJTIwJUUzJTgxJTg2JUUzJTgyJThGJUUzJTgxJUEzJUUyJTgwJUE2Q29tcG9uZW50JUUzJTgxJUFFJUU1JTg3JTlEJUU5JTlCJTg2JUU1JUJBJUE2JUUzJTgwJTgxJUU0JUJEJThFJUUzJTgxJTk5JUUzJTgxJThFJUVGJUJDJTlGJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1jOGY3Y2RiNjMzMDEyZjBhNzQ5N2QwZmZjOWNjNDhhNQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBha2kyMDImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTJjNjBhMzNhZGYzMmE4NzAwNmU5NWY3YjYxZWJmOGE2%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D946faf220f1f913fef4c68b6624214c8)
Appleを追い出されNeXTを立ち上げたスティーブ・ジョブズを間近に見ていたエンジニアたちの証言
1985年にAppleを追放されたスティーブ・ジョブズ氏が創業した「NeXT」は教育用・ビジネス用のワークステーションのメーカーで、1996年にAppleに買収され、ジョブズ氏がAppleに返り咲くきっかけとなりました。NeXTが開発したオブジェクト指向型OS「NeXTSTEP」はその後のmacOSやiOSの基盤となっています。さまざまな質問に対して専門家が回答する質疑応答サイト「Quora」に投稿された「NeXTのエンジニアはどんな感じで働いていたのでしょうか？ジョブズ氏は普段から従業員と交流していたのでしょうか？」という質問に対して、当時を知るエンジニアたちが回答しています。 What was it like to be a software engineer at NeXT? Did workers interact with Steve Jobs? - Quora https://
未開の星で工場のラインを組み上げていくゲーム「Factorio」が得意な人はソフトウェアエンジニアに向いている
未開の惑星でなんとか素材をかき集めて工場を作り、宇宙船を作って星からの脱出を目指すリアルタイムシミュレーションゲーム「Factorio」が得意な人はソフトウェアエンジニアに向いているということを、エンジニアのKrishna Sundarramさんが自身の経験をもとに主張しています。 Factorio and Software Engineering · Krishna's words https://blog.nindalf.com/posts/factorio-and-software-engineering/ 「Factorio」は、未開の惑星に漂着してしまったプレイヤーが、素材を集め、加工工程をじわじわと自動化して、最終的には星からの脱出を目指すゲーム。2012年にアルファ版がリリースされて、どんどんとバージョンアップを重ね、2020年8月にとうとう正式版・バージョン1.0がリリース
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
