サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
大規模言語モデル（LLM）によるコード生成は、ソフトウェア開発の風景を一変させた。しかしその裏で、多くの開発者はある種の「雰囲気（vibe）」に頼ったコーディングの危うさを感じ始めている。MITの研究チームが、この課題に正面から向き合う新しいソフトウェア構造パターンを提案した。それは「概念（concepts）」と「同期（synchronizations）」という2つの要素を核とし、人間とAI双方にとって「可読性の高い（legible）」ソフトウェアを実現しようという野心的な試みだ。AIが暴いたソフトウェア開発の「不都合な真実」 現代のソフトウェアは、その内部構造が極めて複雑化している。一つの機能、例えばSNSアプリの「シェア」ボタンを実装するだけでも、そのロジックは投稿、通知、ユーザー認証など、コードベースの複数の場所に散らばってしまう。MITコンピュータ科学・人工知能研究所（CSAIL
業務にそぐわないパッケージソフトウェアを導入したから訴えます。選んだのは私ですが：「訴えてやる！」の前に読むIT訴訟 徹底解説（126）（1/3 ページ） 連載目次 パッケージソフトウェア、クラウドサービス、生成AI（人工知能）のLLM（大規模言語モデル）など、ユーザー企業がシステムの重要な構成要素を選定しなければならない場面が、近年とみに増えてきた。 ベンダーの技術者が一からプログラミングしてシステムを開発した時代であれば、ユーザー企業はベンダーに全てを任せ、採用する技術を自らの責任で決めることは少なかった。 しかし昨今は、さまざまな業務を支援するパッケージソフトウェアが複数存在し、クラウドサービスも多種多様である。生成AIにしても「ChatGPT」「Gemini」「Microsoft Copilot」「Claude」など、さまざまな選択肢がある。これらをどう選定して、どのように組み合
「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。 そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの本質を見いだせるのではないだろうか。 ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少な
はじめに 他分野のエンジニアに「1回のミーティングで車載OSについて教えて」と相談されることがあったため、その説明の際に使ったメモ書きを共有する。一応、最初に予防線を張っておくと、私自身、車載ソフトウェア業界に身を置くが、「いわゆる車載OS分野の専門家か？」というとそうでもないし、やや距離のある分野の方への説明なので、ツッコミはお手柔らかにお願いしたい。 ISO-26262機能安全について OSという耽美な響きからGeekでTechな話を期待されたかもしれないが、まず国際標準の話から説明を始める。というのも、この点が生命・財産に関わるソフトウェアと、そうでないソフトウェアを分かつ、大きな前提のため、ここはスキップできない。 機能安全とは？ 国際標準とは世界で統一的なコミュニケーションを図るための規格であり、Terminologyについては他のどんな文書より定義が厳密なものだが、「1回のミー
はじめに ソフトウェアエンジニアでテストマンを生業とする Kuniwak です。今回は家を買うためにやったことを紹介します。 というのも、家を買うためにやったことを知人に話してみたら面白がられたため、誰かの役に立つかもしれないと思ったからです。 なおこの記事はソフトウェアに関する技術の記事ではありません（随所に検証の基本的な考え方などが散りばめられていますが…）。また、この記事で紹介する意見・手法は多分に cocopon 氏の影響を受けています。cocopon 氏の家購入エントリもこの記事と同時に公開されているはずです。 また、この記事はとても長いので先にポイントを説明しておきます。この記事ではライフプランシミュレーションに始まり次のような3Dモデルを作って日照や照明の検証をしていきます。また、3Dモデルを作るだけでは漏れが出るのでさまざまな検証を組み合わせています： 検証のために作った3
イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく
2020年1月に行われた Design Matters Tokyo のセッションでUXライティングについて学んだので記事にまとめます。Slack社でUXライティングに取り組んでいるアンドリューさんのお話で、実際にUXライティングするワークショップも体験したので共有したいと思います。Slack社のアンドリューさんUXライティングとはUXライティングとは、ソフトウェアやインターフェースを言葉で対話可能にすることを目的としたコピーです。 ユーザーの行動フローを理解し、専門用語を使わずに対話できるインターフェースを設計する職種のことを「UXライター」と呼んでいますが、まだまだ新しく誕生した職種のためいろいろと模索しているとのことです。 特にSlackでは人とのつながりの構築を意識してUXライティングに取り組んでいて、 どうやったら人と繋がれるのか。 どうやったら言葉で人と寄り添えるのか。 ど
Photoshop, Illustrator, InDeign, Animate, Lightroom, Dreamweaver, After Effects, Auditionなど、Adobe系ソフトの代替ソフトウェアを紹介します。 有名なものからあまり知られていないものまで、買い切り、オープンソースで無料、日本語対応のものなどいろいろあります。 Photoshopの代替ソフトウェア Illustratorの代替ソフトウェア InDesignの代替ソフトウェア Animateの代替ソフトウェア Lightroomの代替ソフトウェア Dreamweaverの代替ソフトウェア After Effectsの代替ソフトウェア Auditionの代替ソフトウェア 下記ツイートの代替ソフトウェアをまとめたグラフィックはAffinity Designerでデザインされています。 With the re
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、RESTAPIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
http://anond.hatelabo.jp/20160228001028 あれを書いた意図ははもちろん、「ニッポンがんばれ」だ。日本のITを取り巻く状況は変わらないといけない。だからこそディスったのだ。 （保育園落ちた日本死ねと書いた人もおそらく、日本もっとちゃんとしてよ！という意味で書いたのだと思う。） ありがたいことに非常に多くの反応があり一通り全部読ませていただきました。 しかし本当に見たかった「いや、ニッポンはIT大国になれる」という説得力のあるコメントや記事は見つけることはできませんでした。 代表的な意見を(エスパー的に)かいつまんで返信してみます。 主語が大きい → 狙い通りです。ありがとうございました。ドラゴンボールの例え？おまえおっさんだろ？ → 返す言葉もございません。ところであなた様もオッサンでございますか？ITじゃなくても自動車とかあるし大丈夫だよ？ → 車はそ
Lunacy Lunacyは2017年2月現在、アルファ版です。 現在利用できる環境はWindowsの64bit版のみで、.NET Framework（無い場合はインストーラーが起動します）が必要です。 2週間後には、ベータ版がリリースされる予定です。 Lunacyの使い方 当方の環境はWindows7の32bit版ですが、非公開版の32bit用インストーラー無し版を提供いただき、その画面で使い方を紹介します。 LunacyはSketchのファイルを単に開くだけでなく、さまざまな機能を備えています。 ※編集作業はできません。 まずは、Sketchのデフォルトで用意されているテンプレート「Material Design」でSketchファイルを作成しました。
自分の作ったソフトウェアをオープンソースとして公開する。まだまだ敷居が高いようです。人気のソースコード共有サービスGithubも、無償で使う場合にはソースコードをオープンソースにする必要があるのですが、「GitHub 上で公開されているソースコードの半分はライセンス的に問題あり」という話もあるくらいです。 では、なぜオープンソースライセンスが、なかなか適用されないのでしょうか。 その理由としては、 オープンソースにしたくない オープンソースライセンスの適用方法が分からない といったことが考えられますが、前者は、Githubの利用条件に合わないので、そもそも無理があります。 さて、後者の「ライセンスの適用方法が分からない」ですが、前回、Githubのライセンス解説サイトを取り上げた時も、「ライセンスが分からない、めんどう」といったコメントが、いくつか見受けられました。ですから、ライセンス適用
結論から言うと、開発会社というか、弊社mofmof inc.としてはあまり望ましくないなと考えてます。 実はこれについては前々から長い葛藤があって、なかなか結論を出せずにいたんですが、最近少しだけ糸口が見えた感があった。 あっ、mofmof inc.エンジニア兼代表の原田が書いております。 ソフトウェア開発会社というビジネス ビジネスという活動を超超簡単な言葉にしてしまうと「サービスを提供して対価を得ること」だと思うのですが、それに従って考えれば「ソフトウェアを提供する」あるいは「技術力を提供する」というサービスに対して対価であるお金を得るという話は至極当たり前な話。息を吸ったら息を吐くってくらい普通な話。飲んだら乗るなってくらい常識的な話。ちなみにぼくはお酒は嗜む程度には飲みますが、ビールは少し苦手です。 ともすると、出来るだけたくさん営業して、出来るだけ高い金額で受注して、出来るだけ低
印刷する メールで送る テキストHTML電子書籍PDF ダウンロード テキスト電子書籍PDF クリップした記事をMyページから読むことができます こんにちは、日立ソリューションズの吉田です。今回は、「企業がOSSを使う上でのお作法」というタイトルで、企業がOSSを活用する上で考えなければいけないことを、いろいろご紹介していきたいと思います。 なぜOSSを使うのか？ そもそも、企業はどのような目的でOSSを利用しようと思うのでしょうか？ さまざまな調査結果などを見ると、「導入コストや運用保守コストの削減」「ベンダーロックイン回避」などが上位に入ってきます。では、本当にこれらは実現できる目的なのでしょうか？ また、OSSに対する不安としては、「緊急時のサポート」「ベンダー、SIerのサポート」に対する不安や「技術者不足」、「ライセンスの困難さ」や「特許侵害での訴訟」などがあがります。
最近のエンジニアの感覚だと、技術的負債というのを極端に嫌うケースがあるそうですね。技術的負債とは… 行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。wikipedia –技術的負債 この言葉は確かにキャッチーだ。プログラムなんて動けばいいでしょという上司に楯突く時に使いやすい武器になりそうだ。 「負債」という言葉はなかなか面白い比喩である。 では少し、負債という言葉について調べてみると、こういうのが見つかる。 負債は借入金や買掛金などの法律上の債務であるとイメージされがちですが、厳密にいったらこれは間違いです。 すなわち負債とは、法律上の債務に限らず、いずれ会社が負担することになるであろう経済的負担で貨幣額で合理的に評価できるものが該当します。 http://financial.mook.to/accounti
求職市場は恐ろしいものです。しかし、時の試練に耐えるスキルがあれば、路頭に迷うこともありません。今回は、未来に通用するスキルを見分け、身に付ける方法を伝授します。 市場が求めるスキルにフォーカスする 市場が、現在、未来において、価値あるスキルとは何かを決定します。例えば、現在、ソフトウェア開発者の需要が高く、供給は限られています。それを受けて、起業家たちがGeneral Assembly、Dev Bootcamp、Bitmaker Labsといったスクールを立ちあげ、プログラミングや、テック企業で職を得る方法を教え始めています。これは一時の流行ではありません。雇用主たちは、こうしたスキルを今後何年（おそらく何十年）にもわたって求めるでしょう。未来に通用するスキルとは、（健康、安全、実用性などの面で）必要不可欠なものであり、経済にも重要な変化をもたらすものです。テクノロジー関連のスキルはその
自分はプログラマーで、多くのプログラマーと同じように、コードを書く行為そのものが幸せであり、いつまでもコードを書いていたいと思う。 だが30を越えて、今までいくつかの会社でサラリーマンエンジニアとして働いた経験を総合するに、 少なくともこの国でプログラマーで居続けるためには起業する以外の選択肢は無いのだという結論に至った。 良いコードを書くと出世してコードが書けなくなる普通にコードを書いて、スキルを磨いて、リリースを成功させていくと、やがて肩書きがついて雑務に振り回される日々が訪れる。プログラマーにとって何よりも大事なのは連続した集中、それも出来るだけ長い時間だ。 昇進して部下が出来たり、質問される機会が増えたり、評価業務やら、上級職会議やら、採用面接やら、一つ一つは大した事が無くても、 出社時間は気が付けば断片化して切り刻まれ、一日に一時間続けて集中する事すら困難になってしまう。 もは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
