納入された業務アプリケーション。作ってくれたIT部門、SIerの皆さんには感謝しつつも、「コレジャナイ感」が否めない... 何でだと思います？ というご相談をいただくケースがあります。 大概の場合、思いつく要因として 要件定義が甘かった ユースケースをもっと提示すべきだった 我社の業務をよく知っている業者に出すべきだった 等が出てきます。業務側の視点に立つと、わからなくはないのですが、これ、全部間違ってます。この視点で考えていたらいつまで経っても同じ感覚に陥ります。視点を大きく変える必要があります。 要件定義をもっと柔軟に まず、プロジェクトがWarterfallであること自体を考え直したほうが良いです。要件定義を「最初に」完璧に出せるところってあるんでしょうか？そんなスーパーレディ・スーパーマンがいたら、地球上から炎上プロジェクトなんて存在するはずがありません。人間、過去にやってきた内容
こんにちは、Necoプロジェクトのsatです。 本記事ではKubernetes(以下K8sと記載)アプリケーション(以降アプリと記載)の開発を高速化するツール、Telepresenceを紹介します。 最初に結論を書いておくと、Telepresenceは次のようなツールです。 ローカルで動くプロセスやコンテナをk8sクラスタの中で動かせる 既存のDeployment内のコンテナを上記ローカルコンテナで置き換えられる テストやデバッグのためにいちいちコンテナイメージをレジストリにpush,そこからpull…とする必要がないので開発速度が上げられる Telepresenceは現在Cloud Native Computing FoundationのSandBoxプロジェクトです。 Telepresence登場の背景 前節において"開発を高速化する"と書きましたが、まずはTelepresenceを使
「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか：10個のヒントとは？ プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合はどうしたらよいだろうか。Red Hatのソフトウェアエンジニアが、コードレビューを行うに当たって念頭に置くべき10のヒントを解説した。 Red Hatでソフトウェアエンジニアを務めるデビッド・ロイド氏は2019年7月8日（米国時間）、コードレビューを行うに当たって念頭に置くべき10のヒントを同社の開発者向け公式ブログで解説した。プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合に役立つ指針だ。コントリビューター側としても参考になる。 これらのヒントは、客観的で的を射たレビューを行い、プロジェクトとその参加者を前進させるという観点からまとめられている。 （1）
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
A full-featured HTTP Client Building great software is hard, and developer tools should be helping you without the headaches. RapidAPI for Mac is exclusively built for macOS, so you should easily get the hang of it. Every feature is built intuitively with quick mouse or keyboard shortcut access. Learn more about RapidAPI for Mac as an HTTP client Describe your APIs Visually build your API requests
一昔前、「厚い財布」は、お札をどっさり入れて高級店に出入りする「お金持ち」の象徴だった。貨幣と交換でモノやサービスを買う社会では、お財布の厚みによって受け取れるモノやサービスの量が決定されたからだ。 しかし、クレジットカードや電子マネーが普及して高額の現金を持ち歩く必要性がなくなった現在では、厚い財布は「スマートさに欠ける人」を指す表現になっている。大量の現金を持ち歩くのは不用心だし、クレジットカードやポイントカードなどで財布が膨らんでいると「お得」や「特典」といった言葉に踊らされている人だと思われがちだからだ。 情報システムの納品物となるドキュメントも、かつてはその厚みが数億円ものコストを象徴していた。基幹系システムなら、ドキュメント一式でキャビネットが数段占有されるのが当然のことだった。 しかし、いまや紙のドキュメントはお荷物。更新が大変なのでソースコードと乖離しやすいうえ、同時に複数
Let op! Internet Explorer wordt niet meer ondersteund. Hierdoor kan de website mogelijk niet goed functioneren, gebruik een alternatieve browser om optimaal gebruik te maken van deze website. Klik hier om een alternatieve browser te downloaden. Home » TIOBE Index TIOBE Index for January 2025 January Headline: Python is TIOBE's programming language of the year 2024! Programming language Python has
はじめに 言いたい事はわかるんですけど、ふわっと言葉を使っていると間違っていることもあります。 ということで、ほとんど自戒なのですが、今や私も気になる部分は多々あるので、私が思う気を付けたらいいよっていう言葉のリストを以下にあげます。気をつけましょう。 なお、本稿では実際の定義は皆様に調べていただく方向ですので、書いておきません。これ調べたらいいよ的なガイドワードくらいです。 証明する 例えば「このテストによって証明されている」これやばいですね。 テスト界隈からも証明プログラミング界隈からも数学界隈からも目を付けられます。 少なくともそれはなごやに囲まれる事を意味します。 基礎 書籍や記事やイベントで「基礎」とみかけますが、結構な割合で入門と勘違いしているケースがあります。それはよくないです。基礎 と 入門は違います。入門向けな予定なのに、基礎と書いたがために、こわい人たちが大挙した勉強会
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 今年からフロントエンドエンジニアにシフトチェンジして5ヶ月がたち、これがないと仕事にならんわレベルのツールを整理がてらに晒していこうと思う。 スペック的にはJava歴が10年くらい。 割とツール好きで、できればキーボード（カーソルキー以外）だけですべての操作を完結したいと思っている。 そんなおっさんがお送りします。 5ヶ月間のお仕事内容 PC/タブレット向けのAngularJSを使ったフロントエンド開発 HTML/CSS(SASS)/Javascript PCはIE8~、Chrome。モバイル端末はiPad、Nexus7 職場での
この書籍に関連する記事があります！ はじめに 本書は「チーム開発実践入門」です。読者のみなさんの中にはよくご存じの方も多いかとは思いますが，チーム開発というのは複雑で難しいものです。 チーム開発を円滑に行うには 本誌の読者の中にソフトウェアやサービスの開発を仕事にしている方もいるかと思います。 第1章 チーム開発とは 1.1 1人だけでも開発はできる 1.2 チーム開発で直面する課題 1.3 どのように課題に立ち向かうか 1.4 本書の構成 第2章：ケーススタディ 第3～5章：基礎的なプラクティス 第6～7章：継続的デリバリーとリグレッションテスト 1.5 本書を読む前の注意点 最適なプラクティスはケースバイケース どのツールを使うかに正解はない 第2章 チーム開発で起きる問題 2.1 ケーススタディの前提 プロジェクトの前提条件 2.2 ケーススタディ（1日目） 問題1：重要なメールが多
topcoderというと「競技プログラミングのサイト」というイメージを持っている人が多いだろう。もちろん今でもその性格は色濃く残っているが、最近では「企業がシステム構築（SI）に利用できるサービス」という面が強くなっている。企業が、自らが必要とするソフトウエアの開発をtopcoderでコンテストとして掲示し、そのコンテストに参加するプログラマの解答を募るのだ。 クラウドコンピューティングに強みを持つSIerの米Appirioは、2013年9月にtopcoderを買収した。Appirioの日本法人であるアピリオ 代表取締役社長の藤田純氏（写真）によると「93％強の案件で、コンテスト開催企業が満足する解答を得られている」という。逆にいえば、失敗率はわずか7％弱。一般的なSIでどれだけの顧客が結果に満足しているかを考えると、驚くべき数字だ。Appirio自身も、顧客のシステムのプロトタイプ作成や
私は色んなプログラミング言語を触るのが病的*1に好きで、どの言語をどういう場面で使うのが良いのか凄く興味があります。 そこで、今の私の知識範囲でのそれぞれのプログラミング言語の使いどころを（自分用の整理もかねて）書いてみます。 C/C++ - C＝OSやミドルウェア、C++＝効率化のための再実装 安直に「メモリとスピードが第一優先のとき」と思いたいところですが、同等程度のスピードでもっといい言語はいっぱいあります。計算集約的ならJuliaとか、オブジェクト指向で組むようなソフトならD言語とか。なのでまずC言語は、Swigみたいのを使って他の言語の拡張ライブラリを書いたり、システムコールを使ってOSやミドルウェアを書くときじゃないかと思います。C++はテンプレートを駆使したりして効率を維持しながら抽象度の高いコーディングをするような場面がしっくり来ると思います。既に他の言語で実装したソフトウ
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
Gitホスティングサービスで開発者から絶大なる支持を受けているGitHubが、ハック可能な新世代のテキストエディタ「Atom」を開発中であることが明らかになりました(公式ブログ、The Next Web、Hacker News)。 現在Mac版Atomがクローズドベータの段階で(Windows / Linux 版はまだ準備中らしい)、まだ一般公開はされていません。ベータテストに参加したい人はメールアドレスを登録して、inviteをリクエストする必要があります。 Atomの見た目はSublime Textっぽいモダンなもの。ブログによると、Sublime / TextMateが提供する簡単さと(しかし拡張性に乏しい)と、Emacs / Vimが提供する柔軟性(しかし複雑な)、を全く妥協することなく結合することを目標として開発されているようです。 GitHubだけに、Webアプリかなという気も
プログラミングもクラウドへ―― 学習＆開発環境Webサービス23選まとめ：安藤幸央のランダウン（67）（1/3 ページ） オンラインのプログラミング環境や、オンラインでコードを書いて学べる学習サイト9選、ビジュアル（子ども向け）プログミラングWeb環境5選を紹介する。 道具としての開発環境 今となっては昔のことですが、机の上でノートに鉛筆でソースコードを書いてプログラミングしていた時代がありました。現在のプログラミング環境から振り返ると、そういう作業はアルゴリズムを考え、頭で想像したコードを書き下ろしており、脳内エミュレーターのようなものだったのかもしれません。 最近のプログラミング環境は、規模も複雑さも肥大化しつつ、プログラミングに関する情報もツールも大変充実したものです（マイナーな環境の情報が少ないことや、新古の情報が混在している問題はありますが）。 Web上の情報も書籍も豊富で、自分
知識ゼロから学ぶソフトウェアテスト 【改訂版】 作者: 高橋寿一 出版社/メーカー: 翔泳社 発売日: 2013/12/10 メディア: 単行本（ソフトカバー） この商品を含むブログ (4件) を見る 読むきっかけ 1年ちょいくらい前からでしょうか。ソフトウェアテストの世界で活躍する方々(JaSST とか WACATE とか) に出会う機会がありました。で、現在縁あってその人達と仕事をする機会が生まれたのですが、テストってちゃんと学んだことなかったんですね。そこで試しに JSTQB-FL の問題に100問くらい臨んでみて4割くらいは怪しい結果(合ってても自信が無いやつが多い) だったので「知識足りないなぁ」と。じゃあJSTQB-FLでも勉強するか？といったところ、人気のある入門書が改訂されたとの情報を得て読んでみました。こっちの方が読みやすそうだし。 感想 すごくおすすめ。テストエンジニア
ピコピココード g=ppgraph B=ppscreen:size() Bw=B.width Bh=B.height tex=pptex:load("main.png") function set(p,d) local r r=ppsprite.new(tex) r:pos(p) r.d=d r.t=100 r:tile(2) r.idle=function(s) s:loopAnime(0.1,{2,3,4}) s:move(s.d) if not s.tane then s.d=s.d*0.98 end s.t=s.t-1 if s.t<0 then if s.tane then for j=1,5 do for i=1,360,15 do local x,y x=math.sin(i/180*math.pi) y=math.cos(i/180*math.pi) set(s,pppoi
グーグルがChrome DevToolsの学習ビデオを公開。DOM操作からプロファイリング、メモリリークの発見まで詳しく学べる 学習内容は全部で以下の7つのレベルに分かれており、17本のビデオと、レベルごとに用意された、実際に自分で操作して解いてみる75以上の例題から構成されています。レベルをクリアするとバッジがもらえるようになっています。 Level 1: Getting Started & Basic DOM and Styles Level 2: Advanced DOM and Styles Level 3: Working With the Console Level 4: Debugging JavaScript Level 5: Improving Network Performance Level 6: Improving Performance Level 7: Memo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
