まさるblog

越後在住子持ちプログラマー奮闘記 - Author：まさる（高野 将、TAKANO Sho）

目次

Blog 利用状況

ニュース

著書

2010/7発売


Web掲載記事

@IT

.NET開発を始めるVB6プログラマーが知るべき9のこと

CodeZine

実例で学ぶASP.NET Webフォーム業務アプリケーション開発のポイント

第1回 3層データバインドを正しく活用しよう（前編）

ブログパーツ


書庫

日記カテゴリ

コミュニティ

2009年2月14日 #

第3回長岡開発者勉強会(NDS)参加したよ

2/7(土)、第3回長岡開発者勉強会(NDS)に参加したので、遅ればせながらレポートを。

 

＊　＊　＊

 

当日開始時刻は13:00だったのですが、私は家事をしたりしていたら遅くなり、ギリギリに到着。

会場に入るとすでに皆さん揃っていて申し訳なかったです。

 

さて、最初に主催のcivic氏よりNDSの説明があり、このあたりは12月の時の文書を新しく来られた方に説明したような感じでした。

 

その後、まずは自己紹介。今回の参加者の方々は、12月、1月にもお会いした人ばかりでしたが、今一度顔と名前を一致させるべくしっかりと自己紹介を聞きました。

 

そして、各自のプレゼンへ。今回順番を決めていなかったことに気付き、資料の分量が多く時間のかかりそうな私から発表することになりました。以下プレゼン順に。

 

Let’s Enjoy C#!：まさる

Lets Enjoy C#!
View more presentations from masaru_b_cl. (tags: nds c#)

質疑応答

  • 普通のforとLINQではパフォーマンスの違いはどうか？
    • LINQの中身はforeach
    • 複雑なLINQはforeachが多く使われるので、その分重くなりがち。
    • とはいえ、パフォーマンスは計測、改善、再計測が大前提なので、一概には言えない。
      • 扱うデータ、データ量など多くのパラメータに左右される
  • Monoプロジェクトの現状は？
    • 追っていないので詳しくはわからないが、ASP.NETが動いたという記事を見たことがある。
    • もちろんC#のバージョンアップにすぐ追随するわけではない。
    • Moonlightがリリースされ、Silverlight互換が動く[アフターフォロー]
  • C#のいいところを紹介したが、いやなところはないのか？
    • やっぱり.NET Frameworkが必須なところ。
      • エンタープライズ用途ならともかく、個人利用でインストールするにはあまりにも大きい。
      • .NET Framework Client Profileなんてのもあるが、インストールできる条件が厳しい
  • C#のバージョンが上がった時の対処は？（.NET Frameworkのバージョンについて回答）
    • 古いバージョンのものは原理上はそのまま動くが、動作検証は必須。
    • 新しいバージョンのものは古いバージョンの環境では動作しない。
  • VBとの違いは？
    • VBにできることはC#でも大抵できる。
    • C#にしかできないことはそれほどない。
      • ポインタ利用とか
    • Excelとの連携などはVBの方がやりやすいかも。[アフターフォロー]
      • Optionalパラメータの恩恵
      • 遅延バインディング
    • 最終的には好みの問題
      • 個人的にはC#が好き！
  • SIでのC#の利用状況は？
    • やはりVBの方が多い。
      • 過去の資産を受け継ぐため？
      • 中括弧言語へのアレルギー
  • C#を選択すべき状況
    • サーバサイドのプログラムであれば、どの言語でもいいと思う。
      • APサーバ（Webサーバ）の選定が影響する。
      • LinuxサーバならApache
        • つまりJavaなどの方が面倒がなく動かせる
      • Windows ServerならIIS
        • C#、VBなどの方が親和性が高い
    • クライアントサイドはOSによる。
      • WindowsならVB、C#が断然優位。
        • Windows APIのWrapperだから。
      • Webアプリならどれでもいいんじゃないかな？
  • LINQ to XMLは今までのXML操作とどう違うか？
    • 簡単な構文でDOM構築できる。
    • 今まではXPathやDOM走査でやっていた処理を、クエリ式で行える。[アフターフォロー]
    • XML記述に関してはVBの方がいいかも。[アフターフォロー]
      • XML構文といって、XMLをコードに直書きできる。

 

１時間かかったので、ここで休憩。

 

思い付きをbotにしようよ！：yutacar氏

プレゼン

  • 前回はWebサービスだったので、今回はWebサービスクライアント
    • pythonでtwitter bot
  • twitterの説明
  • プログラムからtwitterをつつくには、「Twitter API」を使う
    • APIの種類
      • ステータス関連API
      • ユーザ情報関連API
      • ダイレクトメッセージ関連API
      • フレンド関連API
      • アカウント関連API
    • APIはREST準拠
  • Pythonではtwitter用ライブラリがあるのでそれを使うと簡単
  • まとめ？？
    • みんなでtwitter botを作ろう！
  • 小休止
    • TwitterFox使ってたら仕事の効率ダダ下がり！
      • TwitterFoxやばい！
    • 今は使っていない
    • Tweenで貯めておいて、休憩時間に見る感じ
  • 何でPythonか？
    • 大抵のレンタルサーバで使える
    • Google App Engineでも使える
    • Macはプレインストール
  • twitter bot作成に必要なソフトのインストール
    • Python
    • simplejson
    • python-twitter
  • で、どんなbotを作る？
    • 摂取カロリー管理bot
      • レコーディングダイエット
        • めんどい
      • twitterでやればいいじゃん！
        • お前、あったまいい（ｒｙ
      • カロリーAPIを使う（http://soogle.ddo.jp/calapi/）
        • RESTで使用
        • 料理名をPOST→カロリー情報がXMLで返ってくる
  • 進捗
    • ○○のカロリー教えて！→○○のカロリーはxxxです。
  • 課題
    • カロリーAPIに登録してある料理が少ない
      • 自己学習型にする？
    • カロリーAPIから返ってくるカロリーが、小盛りからメガ盛りまである
      • どうしよう？
  • 最後に
    • みんなで思い付きをbotにしよう！
    • できた？と思ったら突っついて。
      • さぼるかもしれないから
    • 摂取カロリー管理botのアイデア募集！

質疑応答

  • カロリーはkcalの方がよくね？
  • pythonに詳しい人、書き方教えて
  • Google App Engineは待ち受けるような動作がきついかも
  • 今回使ったレンタルサーバは？
    • さくらインターネット

 

時間が短めだったので続いて。

 

スタートアップFlash ActionScript 3：civic氏

プレゼン

  • 今回はコード書きながら
    • 細かいところは割愛。雰囲気優先。
  • おさらい
    • Flash作成パターン
      • Fl：Flash CS
      • Fx：Flex + ActionScript
      • AS：ActionScriptのみ
    • 基本概念
      • タイムライン
      • フレーム
      • トゥイーン
      • イージング関数
  • ActionScriptでプログラミング
    • 天地人花火を作る
      • 天地人関係ないやん！
    • 使用するツールはFlashDevelop
    • ステップ１：火の玉
      • FireBallクラスを作成
        • x, y 座標を指定して小さな円を描く
    • ステップ２：動く火の玉
      • Tweenを使って動かす
        • フリーのライブラリを使用
      • deg、長さを指定して移動する火の玉
        • 移動先の位置などはJSONみたいな形式で指定
    • ステップ３：爆発
      • 360度方向に火の玉を散らばす
        • ループで複数のFireBallオブジェクトを作成
      • 火の玉を消す
        • 飛び散った火の玉は消えないと花火じゃないよね
    • ステップ４：上昇してから爆発
      • DispatchEventを利用
        • ある動作終了後にイベントを通知する仕組み
      • 上昇して火の玉が消えた後に爆発するよう設定
    • ステップ５：火の玉の形
      • 三角関数を使って、丸からドロップ状に
  • まとめ
    • 簡単にアニメーションが作れる
      • 単純なものならオーサリングツールなしでも
  • 次回予定
    • Flex
      • ボタンなどのコンポーネントを使ったりする

質疑応答

  • コードでforでFireBallオブジェクトを大量に作って処理しているが、実行すると順次ではなく同時に処理されるのはなぜ？
    • 仕組み上、追加したオブジェクトなどが一つのオブジェクトとなり、実行時にはそのオブジェクトの動作がおこなわれるイメージになるため
    • 上記仕組み上、ずっと待っているようなコードは書けない
      • イベントを駆使して実現するしかない
  • 開発環境はどうやって作る？
    • 全部フリーのものを使っている
      • FlexSDK
      • FlashDevelop
  • コードではなくタイムラインを指定して実行するような場合のやり方
    • CSで説明
      • フミコー氏がCS3を入れていたのでそれを利用
    • フレームごと、オブジェクトごとにコードを記述
    • タイムライン間のジャンプ処理なども行える
    • でもスパゲティソースになりやすい

 

ここでまた休憩。フミコー氏のおみやげの東京ばななパイを頂く。ごちそうさまでした！

そしてここでみんなで名刺交換。私は１回目に渡し忘れた方々にお渡ししました。

いよいよ残り時間が少なくなってきたので、最後のプレゼンに。

 

Let’s Begin TOC：kawakami氏

プレゼン

  • TOC：Theory of Constraints（制約条件の理論）

  • TOCのカバーする範囲

    • サプライチェーン
    • 会計方法
    • 思考プロセス
    • プロジェクト管理
    • 経営革新手法
  • コストワールド vs スループットワールド
    • コストワールド
      • 手が空くのは無駄
      • 作業量がすべて
      • 100%稼働が前提条件
    • スループットワールド
      • 企業のゴール = 業績/利益
      • スループット = 売上 - 資材費
      • コストは考えず、ひたすらスループット
      • 時間当たりのアウトプットが重要
  • スループットを上げるためには
    • ５つのステップ
      • 制約条件の特定
      • 制約条件の活用
      • 制約条件に従属させる
      • 制約条件を強化する
      • 再度、制約条件を特定する
    • 簡単に言うと
      • ボトルネックを改善し、全体の効率を上げ、これをPDCAサイクルで回す
  • TOCのプロジェクト管理への適用
    • プロジェクト遅延の原因
      • パーキンソンの法則
        • マーフィーの法則みたいなの
        • うまくいっていたけど、最後にどんでん返し
      • マルチタスキング
        • 仕事の二股、三股
      • 学生症候群
        • 期限間近で一気にやっちゃおう
        • それまではぬるりと
      • 早期完了の未報告
        • 早めに終えて浮いた時間を余分なことに費やす
      • 遅れの伝搬
        • 一つの遅れが全体へ影響
  • CCPM（Critical Chain Project Management）
    • プロジェクトのスループット改善
      • 工程表、ネットワーク図を元にボトルネックを特定
      • タスクの時間をカット
        • 9-17でぎりぎりできると思って申告した長さをさらに半分に
      • リソースの競合を取り除く
        • リソースバッファを設ける
        • 具体的には予定期日にすぐタスクを開始できるよう、リソースを管理
      • クリティカルチェーンを明確にする
      • プロジェクトバッファを設置する
        • タスクの時間をカットした分を、まとめて最後に
      • 合流バッファを設置する
      • 遅いスタートで計画する
        • 後でできることはなるべく後で
      • 進捗管理をバッファ管理で行う
        • 進捗xx%ではなく、あと何日
  • CCPMの効能
    • スループットの増加
    • リードタイムの短縮
    • 品質向上/仕損じ減
    • 納期遵守度の向上
    • サイクルの短縮による資金回転率の向上
    • 顧客からの信頼向上
  • 今後
    • TOCから発展してCCPM、さらに発展してS&Tツリー

質疑応答

  • タスクが遅れたらどうするのか？

    • プロジェクトバッファを削る
    • プロジェクトメンバ間で合意が必要
      • 一人一人の遅れがPJ全体のバッファを削る
      • ただ、遅れたことを責めるようなことはしない

 

本当はこのあと、前回のRuby on Rails勉強会の主催の林さんがスピーカに立つ予定だったのですが、タイムオーバー。速攻で撤収しました。

 

そのあとの懇親会は17:30～20:30まで。

どんな話があったかなぁ。思い出せる限り。

  • 県内企業の現状
    • やっぱりきびしい
  • これからは小さいプロジェクトを数回さないといかんのでは？
    • でも県内企業の案件は単価がありえないほど低い
  • 書籍執筆経験ってどういうつてで？
    • やっぱり運と縁

＃もう一週間前だからあんまり思い出せない(^^;

 

そんなこんなで、今回も非常にためになり、面白い勉強会となりました。

今回の一番の収穫は、思ったよりもプレゼン後の質疑応答が好況だったこと。

あとは、予定したよりも時間が押して一つ枠がつぶれてしまったので、今後は質疑応答時間もしっかりと予定に入れていかないといけませんね。

 

なお、今回の資料は以下からダウンロードできます。

第3回勉強会(2009/02/07)（http://nagaoka.techtalk.jp/no3）

 

といったところで、今回のレポートを終わります。

なお、次回は3/7(土)です。スピーカ、参加者募集してますので、ぜひぜひご参加ください。

第4回勉強会(2009/03/07)の案内（http://nagaoka.techtalk.jp/no4）
あわせて読みたい

新潟系エンジニア：カロリーを教えてくれるtwitter bot「カロリー太郎」公開！

posted @ 13:40 | Feedback (0)