作ったものが想定した動作をしているか。 それを確認するために、テスト（試験）を行います。 検証したいことがちゃんと実現できて確認が取れているのであれば、その品質自体は割と気にされないことが多い印象です。 保守・運用・追加開発 をしていくプロジェクトが多くあると思います。 その作業の中で、改善を取り入れていくこともあると思いますが、その中でも一番後回しにされるのが、テストコードの改善のように思います。 推測ですが、「コストによるメリット・リターンが少なすぎる」ことが理由かな…と（開発者目線ではリターンが大きいのですが、運用者目線ですとリターンが少なく見えてしまう）。 であれば、最初からある程度綺麗なものがどういうものかを考え、作成しておけば良いのではないか・・！ ということで、考察していきたいと思います。 前提 考察をするにあたり、言語化した時の表現や意味のズレが発生しやすい部分もあると思い

はじめに 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考えるという記事がkenokabeさんという方が挙げていて、拙著の 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡について言及があったので、補考として挙げておく。 暗黙的状態と明示的状態 これまで、関数を「わかりやすくきれいに書く方法」とオブジェクト指向が「どのようにして生まれてきたか」について話してきた。 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 一見、それぞれ関係ないように思うかもしれないが、実は大きなテーマでつながっている。 『それは「状態」をどのように取り扱い単純化するか。』ということだ。そして、これがいわゆる関数型プログラミングとオブジェクト指

はじめまして、次世代システム研究室の A.F. です。 今回のエントリーでは私たちが日々の業務で取り組んでいる『アジャイル開発手法 (スクラム、XP)』の導入事例について紹介させて頂きます。次世代システム研究室の重要なミッションは『GMO インターネットグループの重要なプロジェクトの成功を技術面でサポートする』ことですが、そのため自ずと携わるプロジェクトは多岐にわたります。例えば EC やソーシャルゲーム、広告技術と各プロジェクトで目的も規模もユーザーも異なりますが、Web サービスとして共通しているのはいずれも『変化が激しい』『不確実な要素が多い』という点です。 開発側のスケジュールやリソースといったものから技術的な実現可能性、対象となるユーザーやマーケット、はたまたそれを取り巻く環境など様々な不確実要素を抱えながら開発を行うわけですが、その中で最初から全ての要件を定義することは難しいで

35歳定年説より怖いフルスタックエンジニアしか生残れない未来とは - paiza開発日誌 昔々、SIerでもフルスタックという言葉では無かったのですが、「Ｔ型人材」「Π型人材」になれと言われてきた時代がありました。(今も言われているのかな) この言葉が今WEB業界から出てきたことに、感動を禁じえません。 ああ、SIerのオッサンが、昔訓示をうけた姿がここにある。。。 時折、SIerの昔話みたいな話がWEB業界の最新の話として出ることがあるんですが、歴史は繰り返すってことですね。。。 クラウドでインフラ領域に侵食するオフショア さて、話題のフルスタックエンジニアですが、正直日本国内で優位性を保てるのはあと5年じゃあないかな、なんて予想してます。 フルスタックエンジニアの複合スキルで触れられているシステムのインフラ構築ですが、基本は日本人エンジニアが担当することが多いです。 理由はいろいろあり

最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく

あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし

MPAなWebフレームワーク、Astroの紹介 (その1) 2024/05/17の勉強会で発表されたものです。

忙しい人のための Rocky Linux 入門〜Rocky LinuxはCentOSの後継者たり得るか？〜

Kazuki YamashitaCEO, IA, Experience Designer, UI/IX Designer at IMPATH Inc.

dited by Ryutaro Mori growth hack japan official Twitter account growth hack japan official Facebook account 過度に強調することが出来ないほど重要なプロトタイプ制作。 その重要性は、グロースハックジャパンの記事「グロースハックの大前提 「MVP」の種類と実例 5選」でもお伝えした通りです。 ではどんなツールを使ってプロトタイプを制作すれば良いのか。 ここは多いに迷うところですが、「はやい、やすい、うまい」に越したことはありませんよね？ そこで本日は、吉野家もびっくりの超ハイレベルな無料プロトタイプ制作アプリを、5つまとめてご紹介致します！ 数あるアプリの中でも、使いやすさや完成品のクオリティに焦点をあてて厳選した5つの無料アプリですので、必ずお気に入りが見つかること間違いないでしょう

アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報

2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。

この書籍に関連する記事があります！ はじめに 本書は「チーム開発実践入門」です。読者のみなさんの中にはよくご存じの方も多いかとは思いますが，チーム開発というのは複雑で難しいものです。 チーム開発を円滑に行うには 本誌の読者の中にソフトウェアやサービスの開発を仕事にしている方もいるかと思います。 第1章　チーム開発とは 1.1　1人だけでも開発はできる 1.2　チーム開発で直面する課題 1.3　どのように課題に立ち向かうか 1.4　本書の構成 第2章：ケーススタディ 第3～5章：基礎的なプラクティス 第6～7章：継続的デリバリーとリグレッションテスト 1.5　本書を読む前の注意点 最適なプラクティスはケースバイケース どのツールを使うかに正解はない 第2章　チーム開発で起きる問題 2.1　ケーススタディの前提 プロジェクトの前提条件 2.2　ケーススタディ（1日目） 問題1：重要なメールが多

まえがき 今回はちょっと実践的な？Jenkinsの使い方をしてみる。 なにをやるかっていうと、JenkinsでAndroidアプリをビルドしてapkファイルを作成し、DeployGateにアップロードして実機にインストールするということをやってみる。 開発用のマシンからEclipseでビルドして実機に取り込むのが1番簡単で手をつけやすい方法だけど、複数人で開発している時や複数端末に一斉にインストールしたい時なんかには便利だと思います。 またビルド・テスト（今回は実装していないが）をJenkinsを使って一貫性をもたせるのも色々と便利かと 開発環境 Jenkins （さくらのVPS上に構築） サーバーOS　CentOS6.5 ビルドツール ant 1.9.3 DeployGate フリーのプラン コードリポジトリ GitLab こんな感じの構成でのトライ！ 今回のトライの流れ １．ローカルマ

株式会社プラムザ 代表取締役社長。システムコンサルタント。1998年に28歳で起業し、現在も現役のシステムエンジニア、コンサルトとして、ものづくりの第一線で活躍しつつ、開発現場のチームとそのリーダーのあり方を研究し続けている。 基本的にほぼ100％、社内のプログラマだけで開発を行っている弊社ではありますが、時折どうしてもリソース不足を起こすことがあります。 特にここ1年ほどは、消費税増税に伴ってシステムをフルリニューアルしようというようなお話が多く慢性的な製造力不足に悩まされております。 そんな時は外注の開発会社さんにお仕事をお願いするのですが、これがまあなかなか難しく、これまで結構失敗を重ねてきました。 今回、不肖わたくしめが「たぶんこれが正解じゃないか？？」という案を考えましたので、ここにご提案します。同業者の方々にとりまして何かヒントになれば幸いにございます。 □外注さんとうまくやる

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

株式会社セガのゲームプログラマが書いた、プログラムの初心者に入門書を読む前に読んでほしい「プログラムを根本から理解し考え出す能力を身につける」書籍です。世間一般のプログラム入門書は、プログラムを自分で作るにはどのように頭を動かせばいいのかという根本の考え方を教えてくれません。本書は『ゲームプログラマになる前に覚えておきたい技術』の著者が、プログラミングの未経験者や基本をやり直したいと考えている人のために、簡単なゲーム制作をとおして、プログラムを作る上でどのように頭を働かせればいいのかを学べるように工夫しました。サポートページでサンプルダウンロード、本文「Chapter0 この本は誰に何を提供するか」のpdfを公開しています。 【サポートはこちら】→https://www.shuwasystem.co.jp/support/7980html/3925.html Chapter 0 この本は誰