Android Flashプレイヤー開発から学ぶ 使えるプログラマになるための技術 - 秀和システム あなたの学びをサポート！
プログラミングを少しやったことがある、学校の課題くらいならやったことがあるという初中級者を対象に、Android向けFlashプレイヤーの開発を通して、プログラミングに必要な知識や技術を学ぶ独習書です。Flashの開発は、プログラミングに必要な知識を幅広く必要とするため、総合的な学習に最適の素材といえます。本書ではFlashプレイヤーを自作しながら、本格的な仕様書の読解、バイナリデータ、フレーム管理、ラスター画像形式、ベクターグラフィックス、サウンド再生、ユーザによる入力処理、ActionScriptの実行エンジンをとおしたスタックマシンの学習まで、プログラミングの基礎力をアップさせる課題に取り組みます。サンプル資料のダウンロードサービス付き。 【サポートはこちら】→https://www.shuwasystem.co.jp/support/7980html/3307.html partI
SEMATについての感想 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 昨日、SEA Forumに行ってきて、SEMATについて平鍋氏のお話を聞いてきたことは、 昨日のブログに書いた。 今日は、その感想。 正直なところ、SEMATは、何をどこまで作って、どれが、日本の私たちに、どれくらい影響があるのか、よくわからなかった。実は、ここが一番知りたいところなのだが・・・ つまり、SEAMATは、(以下斜体は、昨日も引用した、平鍋さんのブログ「SEMAT.org にて「ソフトウェア工学再建」運動が開始」から引用） 確かな理論と、証明された原則(principles)とベストプラクティス(best practices)の上にソフトウェア工学を再構築(refound)したい、そのプロセスを支援したい。 っていうと、根本原理からどんどん発展させて、現在のソフトウ
プログラミング言語処理
プログラミング言語処理 講義資料 一覧 全講義資料 pdf版(version 1.1, 108ページ)は、 こちら 言語処理系とは インタプリタとコンパイラ 言語処理系の基本構成 例題：式の評価 ＢＮＦと構文木 解釈実行：インタプリター コンパイラとは ソースコード 字句解析の基礎：正規表現によるパターンマッチ 字句解析と正規表現 自動字句解析生成プログラム：lex 数式の構文解析：top-down parserの作り方 構文規則 top-down parser の作り方 構文解析の基礎 top-down parserとbottom-up parser 上向き構文解析と還元 演算子順位構文解析法 ＬＲ構文解析法 構文解析生成プログラムyacc tiny Cについて tiny Cの言語仕様 tiny C
Androidアプリの使いやすさを左右する5つのレイアウト (1/3) - ＠IT
Androidアプリの使いやすさを左右する5つのレイアウト：Androidで動く携帯Javaアプリ作成入門（5）（1/3 ページ） 本連載で、SDKとEclipseを使ってAndroidの携帯端末で動くJavaアプリを作成し、Android Market配布を目指しましょう 分かりやすく、入力しやすく、カッコいいAndroidアプリを 前回の「簡単でワクワクするAndroidウィジェット10連発！」で紹介したとおり、Androidのウィジェットはケータイとは思えないほどリッチなものです。ただ、どんなにリッチなウィジェットも、それ単独では役に立ちません。ウィジェットを使うには、画面のどこに配置するかを決めなければいけません。 そこで今回は「ウィジェットをどのように効果的に配置するか」というのがテーマです。ウィジェットを配置するには、Androidの「レイアウト」という仕組みを利用します。ウィ
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
d.y.d. 2倍だけじゃない
10:01 10/07/20 それでも２倍だ 先日のvectorの伸長度合いの記事に関して 本当に1.5倍のほうがメモリ効率がよいのか という反応をいただきました。とても興味深い。みんな読みましょう。 自分の理解メモ： 「再利用ができるから嬉しい」等の議論をするなら、 今までに確保したメモリ (1 + r^1 + ... + r^k) のうち、 有効に使えてるメモリ r^{k-1} (バッファ拡大直後) や r^k (次のバッファ拡大直前) の割合で評価してみようじゃないかという。 まず簡単のために再利用をしない場合を考えると、この割合はそれぞれ (r-1)/r^2、 (r-1)/r になります（途中計算略）。 この利用率が最悪になる瞬間 (r-1)/r^2 を最善にしよう、 という一つの指標で考えてみると、式を微分なりなんなりしてみると r = 2 で最大(25%)となることがわかります
きまぐれ日記: 動的配列への追加コストはなぜ O(1)?
動的配列への追加コストは O(1) ってのは覚えていればそれだけの話ですが，どうしてかと言われると意外と難しいものです． というのも, このO(1)ってのは動的配列の実装方法に強く依存しているからです．実装を知っていないと答えられません． 一般論として，1つ要素を追加するとき，配列に空きがなかったら新しく配列を作り直して全要素をコピーする必要があります．コピーのコストは O(n) だから，追加コストも O(n) になるという議論が混乱の元になっています． こういうときは，要素追加を n 回繰り返したときの計算量を n で割った平均をとるという解析方法が使われるそうです．一般に, ある operation C の計算量を C を n 回行ったときの計算量 O(n) を n で割った値 O(n)/n で評価する手法をならし解析 (amortized analysis)と言うそうです． さて，s
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
