第1回ペパボテックカンファレンス http://pepabo.connpass.com/event/13208/
![Engineering in GMO Pepabo, Inc.](https://cdn-ak-scissors.b.st-hatena.com/image/square/1e0d596297f59fce586ab9df3bb5127263124212/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fe4a6936c8f5f4cfd96bdea7365255c91%2Fslide_0.jpg%3F4673941)
In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a summary (or specification or statement) of behavior between inputs and outputs.[1] Functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a syst
Robert Cecil Martin (born 5 December 1952), colloquially called "Uncle Bob",[3] is an American software engineer,[2] instructor, and author. He is most recognized for promoting many software design principles and for being an author and signatory of the influential Agile Manifesto.[4] Martin has authored many books and magazine articles. He was the editor-in-chief of C++ Report magazine and served
ソフトウェア資産管理(ソフトウェアしさんかんり、英:Software Asset Management,SAM)とは、組織において利用しているソフトウェアおよび、それが稼働するもしくは稼働する可能性のあるハードウェア並びに、ソフトウェアを利用するためのライセンスという3つの資産を管理することをいう。Information Technology Infrastructure Library(ITIL)によると、SAMは「ソフトウェア資産の効率的な管理、コントロール、および保護に欠かせないすべてのインフラ基盤とプロセスで、ソフトウェアを利用する間は常に行うもの。」[1]と定義される。 ソフトウェア・ハードウェア・ライセンスの3つの資産を効果・効率的に管理する仕組みを構築し運用することで、ライセンスコンプライアンス(著作権法や使用許諾条件の遵守)への対応で法的リスクを低減するだけでなく、情報漏洩
依存性逆転の原則または依存関係逆転の原則(dependency inversion principle)とは[1]、オブジェクト指向設計の用語であり、ソフトウェアモジュールの疎結合を確立する特別な形態を表現したコンセプトである。SOLIDの五原則の一つとして知られる。 オブジェクト指向における従来の依存関係とは、上位モジュールから下位モジュールへの方向性であり、仕様定義を担う上位モジュールを、詳細実装を担う下位モジュールから独立させて、各下位モジュールを別個保存するというものだったが、それに対して依存性逆転原則は以下二点を提唱している[2]。 上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも抽象(例としてインターフェース)に依存するべきである。 "High-level modules should not import anything from low-le
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
ピーター・コード (英: Peter Coad、1953年12月31日[1][2] - ) は、 ソフトウェアアントレプレナーでありソフトウェア工学に関する書籍の著者である。 コードは、カラーUMLとして知られるようになった技法を説明する役割を果たしたことで著名である[3]。 カラーUMLは、色分けされた記法であり、人が設計やモデルを理解するのを容易にする技法である。 学歴[編集] コードは、アメリカ合衆国のオクラホマ州立大学スティルウォーター校 (OSU) で電子工学を専攻し、1977年に優等学位学士号 (理学) を取得した[4]。 また1981年には、南カリフォルニア大学でコンピュータ科学の理学修士号を取得した[4]。 経歴[編集] 1986年に、コードはソフトウェアコンサルティング企業であるオブジェクト・インターナショナル社を設立し、社長に就いた。 1990年代には、コードはオブジェ
Hired is now LHH Recruitment SolutionsAs of June 14, 2024, Hired is part of LHH Recruitment Solutions, the premier partner for companies seeking contract and direct-hire roles. The decision to bring together Hired and LHH’s offerings reflects the changes we’re seeing in the job market, and the opportunity to deliver a more comprehensive, integrated offering. This includes professional recruitment,
CodeZineを運営する翔泳社では、3月13日(金)に『エンジニアが学ぶ会計システムの「知識」と「技術」』を発売しました。複雑な会計システムを開発するには技術ノウハウだけでなくしっかりとした業務知識も欠かせません。本書では業務に対応する機能をしっかり解説し、クラウドやRPAといった最新トレンドの情報も紹介しています。 『エンジニアが学ぶ会計システムの「知識」と「技術」』では、あらゆるビジネスの根幹をなす会計をテーマに、その業務知識とシステム開発に関するノウハウを解説しています。 企業には販売管理や人事管理など多くの業務システムがありますが、会計システムはそのいずれにも密接に関係しています。会計システムを開発・保守するにあたって会計の基礎知識はもちろんですが、会計が他の業務とどう関わるのかを知ることも必要です。本書では両方のポイントを押さえながら、どのようにシステムを構築していけばいいのか
技術書典8が新型コロナウイルスの影響で中止となりましたが、運営のみなさまがなんとたった10日で作り上げたオンライン販売基盤を使って行われている「技術書典応援祭」。 技術書典8に出店予定だった方々が3月7日~4月5日までの期間限定で技術同人誌を販売しています。 なんと、ITやIoT会社のTech Bookが15冊も無料で販売されています。会社のPR的側面もあるとは思いますが、いずれもビジネスレベルでの開発にまつわる有益な知見ばかり。読まない手はありません。大感謝です。こういったことができる会社は経営層と開発者のコミュニケーションも活発に行われているのだろうなー、と想像できますよね。 本記事では2020年3月13日現在無料で公開されている技術同人誌15冊を紹介します。(見落としがあったらごめんなさい) これをきっかけとして他の技術同人誌を手に取るのも世界が広がって良いですね。私は有料本も6冊買
今日は地味な話をしたい。といってもいつも地味な話だが。コードや区分の設計は良いシステムを設計するうえでとても大切である。設計にあたっては業務要件をみたすためにどんなコードや区分が必要かという視点が最初にくるのはもちろんだが、それ以外にも考慮すべきことがある。変なコード設計のもとでプログラムを書くと条件判定が複雑化し、読みにくく変更しにくいシステムができあがる。 ここで書くことは、経験のある設計者はたぶん(私のように)先輩から教わるとか自分で体得しているのもので目新しくはないが、まとめて整理してある本も意外にないようである(私が知らないだけかもしれない)。 無意コード化 無意コード化とはコードの各桁に意味を持たせないことである。これは、わりに良く知られている原則だ。「コードの各桁に意味を持たせる」とは、たとえば品番の頭1桁が"9"ならサービスパーツと判断するといった処理をプログラムのなかに記
はじめまして。 今年の6月にネクストイノベーション株式会社(以下弊社)に入社したWebエンジニアの大山と申します。 私が弊社に入社してすぐ、弊社が運用しているサービス「スマ診」のアプリケーションを再構築して大幅リニューアルするプロジェクトが始動し、私も参加することになりました。 現在このプロジェクトにはWebアプリに2名、iOS, Androidアプリに2名と計4名のエンジニアがアサインされています。私は現在Webサーバサイドの開発をメインに担当していますが、プロジェクト初期からWebフロントエンドやインフラの設計のみならず、サービス全体の設計にも積極的に関わってきました。 そこで今回は「入社してすぐ、システムをイチから作り直すプロジェクトに参加することになったWebエンジニア」が、まずはじめに何をやったのかについて簡単にお話させていただきます。 ちなみに、アプリケーションを「再構築」する
いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く