『Microservices Maturity Model on Rails』へのコメントブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有
Java開発のノウハウを全面公開、NTTの深謀遠慮
「開発人材を増やすため」。NTTは3月13日、Javaアプリケーションフレームワーク「Macchinetta（マキネッタ）」をGitHub上で一般公開した。公開の狙いについて、取り組みのリーダーである夏川勝行ソフトウェアイノベーションセンタソフトウェア開発技術プロジェクトグループリーダ主幹研究員はこう語った。GitHubはクラウド型のソースコード共有サービスで、オープンソースソフトウエア（OSS）の公開でよく使われる。 IT人材の不足は深刻化し、人材の争奪が加熱している。NTTグループは自社のJavaアプリケーションフレームワークをオープンソース化して、他社も利用できるようにする。これを通じて、Macchinettaフレームワークを扱える開発人材のすそ野を広げる。将来的にMacchinettaフレームワークを扱える技術者が増えれば、NTTグループにとって開発人材の獲得が有利になると見込む。
スタートアップの現場で役立つ開発要件のまとめ方
こんにちは。ハウスマートの高松(@t2kmt)です。 皆さんは開発要件をまとめるのにどんなフォーマットを使っていますか？ 開発要件をいい感じにまとめるのって大変ですよね。 ドキュメント整備せずに開発に着手し始めてしまうと手戻り抜け漏れが出てしまいますが、一方で要件定義書をガチガチなフォーマットにするとドキュメントの作成自体の工数が増えてしまいます。 スタートアップはスピードが命。ドキュメントを書きまくって開発が進まないなんて言語道断です。 開発要件の整理はプロジェクトの成否に多大なインパクトを与えますが、ほとんどの現場では企画を考える人にフォーマットが委ねられていることが多いと思います。 今回は皆さんが快適に開発要件をまとめられるように、ハウスマートで利用している mini spec というフォーマットをご紹介します。 mini spec とは mini spec とは開発の要件をまとめる
xUTP Magazine - xUnitester Hotlinks: 第一回 和田卓人さん(下)
xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。 栄えある第一回のインタビューは、日本の TDD 伝道師、和田卓人さんにお願いしました。 こちらは後編となります。前編はこちら 和田卓人（わだたくと） タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP（eXtreme Programming）を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い（完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念）」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催するなどして、テスト駆動開発を広めよう
実践テスト駆動開発(GOOS)読んだ - Qiita
実践テスト駆動開発を読んだ（和智さんいい仕事、ありがとう！）。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト（TDD）」と「オブジェクト指向（Object-Oriented）」と「育てる（Growing）」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは！」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト（ユニットテスト）と外側のシステムテスト（受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
なぜいま Heroku なのか - Qiita
開発中のサービスに Heroku を採用した経緯を社内で周知するために書いた文章なんですが、ついでに Qiita にも貼っておきます（ちなみに Heroku の回し者ではないので悪しからず）。 従来、Heroku は日本で使うにはレイテンシの問題で本番環境での利用が避けられることが多かった これは Heroku の Common Runtime には Tokyo region がなく US 等のサーバーと通信するとレイテンシが大きいため1 実際、Wantedly 社なんかもレイテンシを理由に Heroku から AWS に移行している だが、Service Worker の先読みと Fastly（のような instant purge 可能な CDN）の登場により、このレイテンシの影響は極小化された のではないか 多くのリクエストは Fastly のエッジサーバー からレスポンスを返せるはず
Android開発をする上で知っておいてほしいなと思うこと - こやまカニ大好き
現在の Android Developers の情報は非常に充実していて、Developer Guides を順に読み進んでいくだけで開発に必要な知識とGoogleが想定している(であろう)最も基本的な実装を学ぶことができる。 特にこの「基本的な実装」というものが重要で、これを知っておかないと開発者間の意思疎通がスムーズに行えなかったり、そもそも気をつけておくべき注意点を見落としがちになってしまう。 とはいえ、今の膨大な公式ドキュメントをただ読めというのは厳しいので、Android開発をする上で最低限理解しておいてほしい(と僕が思っている)事柄と、それについて知ることができるドキュメント類についてまとめてみることにする。 2018/03/25 : リリース周りについて別記事に追記した。 nein37.hatenablog.com 公式ドキュメントの重要ページ 公式ドキュメントと言った場合、
Zoho Creator と kintone の比較
きっかけ 中小企業が自分達で業務システムを作れると良さそう 地方の中小企業のIT化をサポートする仕事とか出来ないかと、何となく考えていて、過去に何回かブログで触れました。（「 何に特化するか」、「商工会議所に加入しました」） 1つの方向性として、地方の中小企業がSIerに丸投げするのではなく、自分達で主体的に（必要に応じてSIerをうまく利用して）業務アプリを作れるようになると良いと考え、そういうののサポートをしたいと考えていました。 具体的には、単なるシステム導入だけでなく、IT化に関するトレーニングなども実施していければと考えていました。 それ、 kintone なら出来るよ そうした中、プログラムの知識がほぼ不要で業務アプリを作れる kintone の存在を知りました（というか思い出しました）。 幸運なことに、たまたま、周りに kintone に非常に詳しい人物がいて、その人から長所
Mendix｜株式会社ビルドシステム
ローコードとは何か？ ローコードとは、コーディングをテキストからビジュアルに昇華させるアプリケーション開発手法である。 技術的なコーディング環境ではなく、ローコードはモデル駆動型のドラッグ＆ドロップ・インターフェースで動作します。プロの開発者、初心者の開発者、サブジェクト・マター・エキスパート、ビジネス利害関係者、意思決定者など、あらゆる開発スキル・レベルの人が、ローコードを使用して価値主導型のエンタープライズ・ビジネス・アプリケーションを構築できます。 ※さらなる可能性を見る ローコードの特徴と利点 ローコード・アプリケーション開発プラットフォーム（LCAP）は、アプリケーション・ライフサイクルのあらゆるステップを抽象化し、自動化する。 開発プロセスを加速する機能により、技術的な専門知識を持たないユーザーでも開発にアクセスしやすくなります。 ビジュアル・モデリング ドラッグ＆ドロップ機能
Best Low-Code Development Platforms Software in 2020 | G2
Low-Code Development Platforms reviews by real, verified users. Find unbiased ratings on user satisfaction, features, and price based on the most reviews available anywhere. Low-code development platforms provide development environments that allow businesses to develop software quickly with minimal coding, reducing the need for extensive coding experience. The platforms provide base-level code, s
Low-code development platform - Wikipedia
A visual low-code editor that enables the creation of process logics without programming knowledge, illustrated with an example from Peakboard. A low-code development platform (LCDP) provides a development environment used to create application software, generally through a graphical user interface (as opposed to only writing code, though some coding is possible and may be required). A low-coded p
MailHog - 管理画面付きな開発用メールサーバ
システムでメールを使うことはよくあります。ユーザ登録や通知などによく使われます。しかしこのメールは開発中は取り扱いに困ります。間違って送信されると困りますし、ちゃんと表示がうまくいっているか確認しなければなりません。 そこで使ってみたいのがMailHogです。開発時に使えるSMTPサーバです。 MailHogの使い方 メイン画面です。 Web通知機能があります。 MailHogのSMTPサーバを使うとメールが管理画面で確認できます。 日本語も問題なく扱えます。 MailHogを使えば開発時のメールサーバとして、その内容が正しく届いているかどうか確認できます。誤って送信されてしまうこともないので安心です。開発用メールサーバとして使ってみてください。 MailHogはGo製のオープンソース・ソフトウェア（MIT License）です。 mailhog/MailHog: Web and API
自立自走型チームの構築と心理的安全性を高める施策 - Qiita
はじめに ※大層なタイトル書いてるけどただの日記みたいなもんです ※あくまで個人の見解であり、所属する団体・組織の見解ではありません 現在自分は客先常駐型でエンジニアの派遣を行う事業をメインとする会社で、小規模ながら社内で受託開発を行う部署に在籍している。その組織の仕組みは「プロジェクトマネージャー」と「組織の管理職という肩書としてのマネージャー」が兼任になることが（自分も含め）ほとんどだった。なんでもできるマネージャーがタスクを分解、できそうなメンバーにアサインし、メンバーはタスクをこなすのみに注力という構図で、以下のような問題が起こっていた。 マネージャーが非常に多忙でSPOFになるケースが多々。とてもじゃないが休めない できる人のみにタスクが集中し、できない人は本当に何もしてない メンバー間での責任の押し付け合い マネージャーからメンバーに対する高い圧力 やる気があるメンバーのモチベ
社内勉強会で障害対応体験ゲーム『障害対応Night☆』をプレイしました - Feedforce Developer Blog
フィードフォース ボドゲ部の id:kano-e です。 先日の社内勉強会で、障害対応体験ゲーム『障害対応Night☆』を技術チームメンバー何人かにプレイしてもらいました。 「障害対応体験ゲームって何？」とお思いでしょうか。 障害対応体験ゲームとは、架空の Web サービスで障害が発生したと仮定し、それに対してそれぞれの知識と経験と技術を集結して対応する……ということを体験できるように、わたしが考えたゲームです。 『障害対応Night☆』という名前は 10 秒くらいで考えました。 そもそもなんでゲームなんか考えたのか、どのようなゲームか、プレイ風景や参考情報などをまとめました。 そもそもなんで「障害対応体験ゲーム」なのか 障害対応って経験や場数による部分があるよね、という感覚が薄っすらとあるような気がしてます。 じゃあ、どうやって経験を積めば良いのかというと、それはもう実際に障害が発生する
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
「ソフトウェア開発データが語るメッセージ2017」を公開～ソフトウェアの信頼性は向上するも生産性は低下傾向～：IPA 独立行政法人 情報処理推進機構
概要 独立行政法人情報処理推進機構ソフトウェア高信頼化センター（以下、IPA/SEC）は2018年3月6日、「ソフトウェア開発データが語るメッセージ2017」（以下、本書）を公開しました。 本書は、「ソフトウェア開発データ白書2018-2019」（2018年10月発行予定）作成用に収集した最新のプロジェクトデータに基づいて、ソフトウェア開発の傾向を分析したものです。 分析の結果、ソフトウェア開発の信頼性は向上しているものの、ソフトウェアの品質に対する要求の高まりにより、生産性は低下傾向にあることが分かりました。また、生産性・信頼性の向上には定量的管理を推進し、品質要求レベルに見合った生産性目標を設定すべきこと、さらに、要員の人材育成が重要であることが分かりました。 背景と目的 近年、ソフトウェアの大規模化／複雑化が進む一方、信頼性向上、生産性向上、開発期間短縮等の要求は高まっています。この
Pivotal Cloud Foundry 2.0、「Kubernetesに負けた」わけではない理由
Pivotalは2017年12月、Pivotal Cloud Foundry 2.0（以下、PCF 2.0）を発表、これを日本法人のPivotal Japanが2018年3月に国内発表した。最大の目玉は、新製品としてKubernetes環境を提供することにある。 これについて、2018年1月に来日したPivotalの製品担当シニアバイスプレジデントであるスコット・ヤラ氏は、筆者に次のように話した。 「これは、『Cloud Foundryが勝つか、Kubernetesが勝つか』という問題ではない。Cloud Foundryが適している用途では、Cloud Foundryが開発者および運用者の生産性を最も高められる存在だ。だが、Cloud Foundryで全ての用途をカバーできるわけではない。だから選択肢としてKubernetesを提供する。PCFには今後、サーバレスコンピューティング（Fun
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
正しく失敗しながら進むプロダクト開発/railsdm2018
GitHub - mailhog/MailHog: Web and API based SMTP testing
FFTT#309