IPA セキュア・プログラミング講座IPA 独立行政法人 情報処理推進機構 セキュリティセンターによるセキュア・プログラミング講座：Webアプリケーション編 & C / C++言語編
ブラウザってどうやって動いてるの？（モダンWEBブラウザシーンの裏側）
どうも、鈴木です。 さて、前回は vim の使用法というじつに低レベルレイヤの出身者的な記事を書きましたが、 今回も懲りずに低レベルのお話しをしたいと思います。 というのも、先日「ブログ書くのめんどくさいよぅ」と駄々をこねていたところ、あまりにレガシーすぎる HTML/CSS/JavaScript 仕様や Flash や Silverlight といったプロプライエタリなリッチコンテンツ用プラグインに日々苦しめられている気弱く善良な一介の WEB プログラマにすぎない我々の希望の星であり、そして同時に新たな巨大クソレガシーの萌芽でもある HTML5 が、いかにイケてないのではなくイケているのであるかを盛んに啓蒙するサイトである HTML5 Rocks (http://www.html5rocks.com/) に、"How Browsers Work" というとても楽しい記事があるのを、我が
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
無駄な詳細設計書を滅亡させるための処方箋 - aike’s blog
昔は「詳細設計書なんてアホなもん作ってもプログラミングには何の役にも立たないんだよふぁっきゅー！」と言い続けるのが、詳細設計書を滅亡させる手段だと思っていたけど、どうも事態はそんな簡単じゃぁないっぽい。 じゃあ一体どうすればいいのかってのはマッタク思いもつかない。まぁカンタンに無くなるもんだったらとっくの昔に滅びてるわけだしねぇ……もし、解消することが出来たら、ないし処方箋を思いつくことができたら、いつか blog に書きたいです。 詳細設計書が滅亡しない理由 - kagamihogeのblog SIerが作らされる詳細設計書（内部設計書とかプログラム設計書などと呼んだりもします）の評判は相変わらず悪いですね。このへんについては前からいろいろと考えてたことがあるので今回まとめてみます。コーディング時点で必要になる文書を極限まで減らしつつ、ウォーターフォール式の開発で納品物もきっちりそろえる
詳細設計書に何を書くべきか？ - Sacrificed & Exploited
詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと１対１に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容（内部の処理の実装方法）の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、
画面展開の表記方法 – capeknote
iphoneアプリの画面設計をしていて、画面フローの表記をしようとして普通の画面フローチャートだとUIインタラクションを表記しにくいよね、と思ったので考えてみた。 画面フロー図の限界webの画面フロー図は以下のことができないなー、不便だなーと思ってた。 画面展開を表記する記法がない。webだと_blankくらいしかないけどアプリだと不便 画面が内包しているコンポーネントを表記できないので、画面のどのボタンが次の画面につながっているのかわからない。 ↑レベルのを練ろうとするとワイヤーフレーム/プロトタイプをつくる作業になってしまう。プロトタイプだと逆に画面のつながりや展開の法則性がとらえにくく、整合のとれたインタラクションデザインが試行錯誤しにくい そもそも画面展開の種類って網羅的に把握されてる？ 構造化寄りの表記方法は「情報アーキテクチャ、インタラクションデザイン記述のためのビ
iPhone Dev Center 日本語リファレンス
ウィジェットとライブアクティビティ ウィジェットがさらに多くの場所で活用できるようになり、パワーアップしました。WidgetKitを使ってインタラクティブな要素やアニメーションによるトランジションに対応すると、ユーザーがウィジェットから直接アクションを実行できます。既存のウィジェットにわずかな変更を加え、iOS 17向けに再ビルドするだけで、iPhoneのスタンバイ画面、iPadのロック画面、Macのデスクトップ上で視覚的に美しく表示させることができます。SwiftUIを使用すると、ウィジェットの色と間隔がコンテキストに合わせて自動調整されるため、複数のプラットフォームで使いやすさが増します。 WidgetKitとActivityKitで構築したライブアクティビティがiPadで利用できるようになり、ユーザーはアプリのアクティビティや情報をロック画面からいつでもリアルタイムで確認できます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
