TrickDiary このページをアンテナに追加 RSSフィード

2016-10-16

[][][] JXUGC #17 お前の Xamarin アプリを見せてみろ!

http://jxug.connpass.com/event/39470/

keep.grass について発表してきました。

https://github.com/wraith13/keep.grass

keep.grass は近日ストア公開予定の iOS, Android, UWP 向けのアプリで、Github 上での進捗を途切れさせることがないように最終アクティビティを確認および残時間を通知する為のアプリです。

今回、スライドなしで発表してきたんですが、その内容と周辺の情報について簡単に情報をまとめておきます。

Twitter上で日本語縛りで Xamarin ユーザー検索してフォロワー数の降順に並べると自分がどうやら三番目にくるらしく、ホント、なんか申し訳ない。。。

Xam.Plugins.Forms.ImageCircle

概ね問題ないんだけど、 UWP 版の Windows Mobile ではなぜかちゃんと丸くならない。同じ UWP 版でも PC では問題ないし、以前は Mobile でも問題なかったがどこかのタイミングの Xamarin 周りのアップデート以降ちゃんと機能しなくなった。

クルクル

定刻通知

この種の UI は時刻の追加/編集・選択/削除あたりの UI を提供するのが普通だと思うんだけど、それだと開発者として実装するのもユーザーとして利用するのも面倒という誰が得するの?と言う状態になってしまうので

思い切って30分区切りで24時間分のスイッチを並べました。

OxyPlot.Xamarin.Forms

まだ unstable 版なのは承知で手を出してはみたものの以下のような問題があって、いまこのプラグインの代わりに SkiaSharp に移行してるところ。

  • なんか変な線が描画される。
  • Androidでは Resouce.designer.cs が勝手に弄られてそれをそのままコンパイルするとエラーになる。( 変更を破棄して、元に戻せばコンパイルも通るし、自分が試した範囲においては正常に動作した。 )
  • UWPにはそもそも対応してなかった。

SkiaSharp

2014-07-14

[][] Room metro #26 大阪 & VSハッカソン倶楽部 共催

http://metrostyledev.net/index.php/event/20140712/

さおさんの浴衣姿が拝めると聞いて行ってきました!

独りガラパゴス開発

私はこんな発表してきました。

http://www.slideshare.net/wraith13/galapagosdev

他の発表者の発表でいくつか興味深かったものをピックアップしておきますと

EdgeJS

node.js と .NET 間で相互呼び出しを実現する為のフレームワークの紹介で、JavaScriptはとっとと滅んで欲しいという立場からすると非常に残念ではありますが、とても実用的なフレームワークだと思います。

Reactive Extensions

名前自体はよく目にしてたもののどういうものなのか全く把握してませんでした。Reactive Programming のようなパラダイムはそれが必要とされる場面では本当重宝するのでしっかり押さえておきたいところ。

C++ 用の Reactive Extensions もあるようです。

https://github.com/Reactive-Extensions/RxCpp

C# vNext 新機能紹介

C#の新機能について紹介。.?演算子はずっと待ってた機能。変数宣言式は、便利なのはわかるんだけど、本当にこれを許して良いのか不安になる機能。catchにifがつけられようになったけど、これを入れるならもうパターンマッチ導入しろよとw てか、絶対、パターンマッチとして悪用するヤツが沢山でるよね?


・・・とまぁそんな感じ。

全体の流れで言うと、各発表の前にちゃんと丁寧に発表者の紹介をしてくれたのが非常に良かったです。やっぱり発表者の紹介があったほう発表に箔が付いて発表者にとっても視聴者にとっても嬉しいものです。ああいうのはやろうと思っても地味に難しいと思うのですが、自然にさらっとこなしてるさおさんは凄いなぁと。

それから大半の発表者が発表の冒頭に発表することになった経緯に関するネタで天丼やってくれて、大阪ならではなノリを堪能できました。

あと、途中のおやつタイムで551のアイスを頂きました。

お昼に食べたラーメン+炒飯も帰りに食べた本場のたこ焼きもめっちゃ旨かったし、さおさんの浴衣姿も拝めたし、非常に良い1日でした。

まとめ

浴衣は女の子が何割か増しで可愛くなるのでもっと日常的に着て良い。

2013-08-02

[]ハッカーになりたいあなたへ

あなたはハッカーになれません。

虎は生まれながらに虎であり、猫が虎になろうと思っても虎にはなれないように、ハッカーは生まれながらにハッカーであり、ハッカーでない者がハッカーになろうと思ってもハッカーにはなれません。

ハッカーはコンピュータに関わらずとも日常的に様々なハックを行使します。ハッカーはプログラミングを覚える前からハッカーなのです。

2013-08-01

[][]愚者はメールで議論しようぜ!

  • 私の主張としてはメールは通知・伝達あるいは記録の為にのみ使用すべきであり、メールで議論や解説の類いを行うべきではない。
  • メールで議論や解説をする事の問題点
    • 相手に無駄に攻撃的な印象を与えてしまう。
    • メールを書くのはしばしば非常に手間暇がかかるものでありつつ、その上、長文のメールはまともに読んでもらえない事が多く、非効率的且つ非合理的である。
    • 伝えたい内容を相手が正しく理解したかどうかの確認が困難を極め、それが不確かな状態で話を進める事はコミュニケーションのS/N比が下がって行く一方で非効率的且つ非合理的である。
    • 伝えたい内容が適切に伝わるのは奇跡だと前提するべきであり、伝えたい内容を過不足や誤謬無く表現するのは大変な事であり、またその表現をどのように解釈するかは受け手次第で大きくブレる。この為、相手が伝えたい内容を正しく理解したかどうかを常に確認しながらコミュニケーションする事は重要であり、それがまともにできないコミュニケーションはまともなエラーハンドリングがなされていないソフトウェアやハードウェアと同然で目的が果たせないどころか大きな損害をもたらすリスクの覚悟を迫られる事になる。
  • メールで議論や解説をする事のメリット
    • 後から議論の経過を追跡する事が可能。
      • 各決定事項の理由がまとめられていれば良い話であり、まとめがあった方が確認も簡単であり、メール上で議論をする事を肯定する理由としては弱い。
    • 言った言わないの水掛け論を防ぎ易く責任の所在も明確になり易い。
      • 残念ながら個人や会社間での自己防衛として機能する面があり、またそれが必要とされる場面がある以上、この理由は否定し切れない。
      • これが必要となるのはそもそもコミュニケーション上の齟齬に起因するものであり、これが必要になった時点で負けであり、あくまで敗戦処理上の都合だと言える。
      • チームで仕事をする時に自己防衛を考えなければならないというのも、またとても望ましい状態とは言い難く、その状況自体の改善が望まれる。
    • 母国語でないコミュニケーションの場合、辞書や翻訳ツールが手軽に利用できる。

2011-09-20

[][] エラーハンドリング勉強会を開催しました。

ご報告が遅くなってしまいましたが、無事 9/4 にエラーハンドリング勉強会を開催することができました。改めて、会場を提供してくださった DeNA 様、発表者、参加者の方々、ありがとうございました。

自分的にはもっとこうニッチな勉強会だろうと思っていたのですが、結局の所、エラーハンドリングって全てのプログラマが無視するわけにはいかないテーマであり幸いな事に予想外に反響は大きかったようです。

「エラーハンドリングモデル考察」 @wraith13

エラーハンドリングモデルについて考察したいくつかのトピックについて発表させて頂きました。ボリューム不足で大幅に時間を余らせてしまうという失態を犯してしまいすみませんでした。

次にまたエラーハンドリング関連の発表する機会があるとすれば恐らくは tree エラーモデルの実例を交えた解説あたりになるんじゃないかと思います。tree エラーモデルは端からすると仰々しいモデルのように見えるかも知れませんが実のところエラーを投げる側も気軽にバンバンエラーを返すことができ、またエラーリスナーチェーンによってそれを受ける側も非常に効率良くハンドリングできる仕組みを構築できる*1ものだと言うのが私の考えなのですが残念ながら 1 bit たりとも伝わってなさそうなので。(泣

あと、 tree エラーモデルで必須となってくるリスナーなんですが、こいつを外部で差し替えできるようにするのも面白いんじゃないかなぁと思ってたり*2

これができると例えばあるモジュールを使ってた時にそのモジュール的には問題のないエラーだからと握り潰してたら、実は呼び出し元のプログラムではそのエラーが発生するかどうかは重要なポイントで握り潰されたら困るって場面が発生しても、外部からリスナーを差し替えられるようになっていればどうにかなるし、あと、人間系関数まわりの話でも、素のプログラムでは人間系関数も普通の関数と同じように考えてシステム的視点でよいとされるスタイルでエラーを返しつつもエンドユーザーとの緩衝材となるリスナーを挟めば、システム的にも UI 的にもいい感じにまとめ上げられそうだし、同様にデバッグ時にはデバッグ用リスナーを差し込むとか楽しそう。

あと、最近目にしたエラーハンドリングの話題についての自分なり考察など。

  • エラーハンドリングまわりの開発アプローチ
    • 現実から様々なエラーが引き起こされる。言い換えると、実際に多くの試験をこなしてみないことにはどのような問題がおきるかなんてわからない。机上の設計で初めからしっかりしたエラーハンドリングを構築するのは厳しい。多くの試験(本番含む)をこなしブラッシュアップしていくしかない。
  • 一番詳しいのはエラーを投げるモジュールだからエラーを投げる時は解決方法まで提示するべき?
    • そこまでの要求は無茶なんじゃね?
      • 必ずしもはエラーを投げるモジュールが全てを把握できるわけではない。
      • 現実からどのような問題が沸いてくるかわからない。
      • 現実的な範囲で理想に近いものを提供する努力はしたほうが望ましいのは否定しない。
        • エラーハンドリングそのものと同じく多くの試験(本番含む)をこなしブラッシュアップしていくしかないし、多くの場合はそこまで手間暇かけられずに完成度が低いものになってしまう。

cf. 今回の元ネタとなった Boost.勉強会 #3 関西 での発表資料: PPTX版: http://www.trickpalace.net/paper/error.handling.pptx PDF版:http://www.trickpalace.net/paper/error.handling.pdf slideshare http://www.slideshare.net/wraith13/ss-7987895


「エラーハンドリングとアプリの運用」 @super_rti さん

いつものごとく魅せる発表資料で高いテンションに良いテンポの発表で嫉妬しまくりです。

ログまわりは難しいですよね。デバッグの為に大量にログを吐いたところでそれぞれの問題において重要なパラメータがちょっと欠けてるだけで全く意味を成さなかったり、質問で個人情報云々な話の懸念もありましたけど、バグベアードみたいに大量に吐いてると断片的にではあってもソースコードが漏れると言った状態にもなりますし。

cf. 関連する @super_rtiさんの以前の発表資料 http://prezi.com/1jolcfw5y71g/exception/

# よく見ると TRY CATCH になってるw

「ドキュメントとエラーハンドリング」 @cpp_akira さん

ドキュメントとの整合性のお話。

比較的正確なドキュメントが揃ってるだけその点についてはまだましなんですが、無駄にエラーの返し方にブレがある Win32API みたいなのも勘弁して欲しいところです。一部例外的なものがあるとかじゃなくて全体的にブレまくってるから、ちゃんとエラーハンドリングをやろうとすると各APIごとに逐一どのようにエラーを検知するべきか調べて個別に対応しなきゃならんとか非常に不便極まりないですよね。 > Win32API

あ、あと、発表とは関係は無いのですが、魔導書の2巻をチラ見させて頂きました。もうそろそろ発売されるようです。この文章ちんたら書いてるうちに予約開始されてしまいました。

cf. 関連する @cpp_akira さんが作成している資料 https://sites.google.com/site/faithandbrave/error_handling


「スタート例外」 @ranha さん

この年にもなっていまだに女性に対する免疫が低い自分はことりさん (先週、誕生日だったそうでおめでとうございます。)と度々目が合ってドキドキしてしまい話を聞くの集中できませんでした!><

内容については Stack コンテナの具体的な実装について考察。

しかし、度々、勉強会の類いで Haskell のコードを見せ続けられてるせいでいい加減ちょっとずつ覚えてしまいそう。

「Actor モデルとエラーハンドリング(Erlang 時々 Scala)」 @cooldaemon さん

自分的に一番肝だと思ったのは「分散はシステムが複雑になるけど、稼働率を上げるには必要不可欠。」ってあたりでしょうか。

Actor モデルのメッセージパッシングをベースにコードを書くのって恐らく結構独特なものがあるんじゃないかと思うんですがどうなんでしょう?


「失敗するclose()を作る」 @__gfx__ さん

失敗してくれないとエラーハンドリングのテストができないから、失敗する実装に差し替えちまおうというお話。大事です。

「exception_ptrについて」 @egtra さん

スレッド跨いで例外オブジェクトを扱う時には exception_ptr を使いましょうねというお話。

このまわりについては nested_exception 関連で私も以前に調べて、古い情報を元にしてるので C++11 と若干違うところがあるかも知れませんが日本語訳を起こしましたので↓このあたりもご参照ください。

他...

...低レイヤーまわりの話で期待されていたものの今回は残念ながらお話が聞けなかった @mskwt さんは某筋の情報によると、お体を悪くされているそうで容態が心配です。


所感等のリンク

*1:これらの特徴は厳密には tree エラーモデルではなく主にエラーリスナーチェーンによるところが大ですが。

*2:いま対応することを検討していますが、現時点の trickerr.h は内側のリスナーのほうが絶対的な権限を持っており内側のリスナーに握り潰されたエラーは外部でどうこうできません。

2011-04-06

[][] エラーハンドリング勉強会を開催します。【発表者募集中】

【エラーハンドリング勉強会】

http://partake.in/events/9874b92a-4cf0-4a20-a3fe-951239da5612

エラーハンドリングはどのようにあるべきか? 例外クラスはどのように設計するべきか? と言った高レイヤーの話題から Windows の SEH や Linux のシグナルまわりの低レイヤー(※1)の話題までエラー処理/例外処理全般で盛り上がりませんか?

...日時や場所は未定のまんまなんですが、発表者の頭数が揃わず話が滞っちゃってます。

なにやら語りたい人、問題提起したい人等々、ご連絡ください。

発表者になって頂ければ当然開催日時も融通します。

あと、会場の提供者も募集中です。

追記

会場は株式会社DeNA様よりご提供頂けることになりました。

2010-10-25

[][][][] 「Boost.勉強会 #3 関西」で「エラーハンドリング」の発表をしてきました。

発表資料等については http://d.hatena.ne.jp/youandi/20101023/p1 とか http://d.hatena.ne.jp/faith_and_brave/20101025/1287979418 あたりを漁ってください。

発表について

  • 前回の反省から今回は早めに動き出していたものの、発表内容で欲をかき過ぎたせいでいろいろ失敗してしまいました。
  • 資料作成に手間取っていたのとどのみち発表時間枠的に無理だと途中で判断し断念しましたが、本当は assert の密度と同じ密度でその続きもやりたかったです。
  • 顔文字はほぼ全てのページに挿入する予定でしたが、これも時間の都合で断念。
  • 寝不足のせいでリスナーとしてもせっかくああいう場で生で聴いてるのにいろいろ台無し。
  • 私が RedBull で買収して発表順を代わって頂いた方も実はその直前まで私の隣で資料を作成していました。

懇親会

  • お店に向かう列の最先頭グループにいたあんどちんさん( @ )はお店を直前にしたところで、別にお店に吸われてしまいました。
  • 我が妹( @ )に絡みに行こうとしたら良い場所が無かったのでとりあえず近くのしばやん( @ )のところへ行ったら、しばやんが超饒舌で、会話してるともの凄く喉が渇きました。
  • しばやんに手持ちのメイドさんが出てくるお店のカードを沢山見せてもらいました。なんであんなに沢山のお店のカードを持っているのか意味が分かりません。
  • 本当の兄弟なの?ってぐらい、しばやんは某変態のお兄さんに雰囲気がなんか似てました。
  • You&I さん( @ )が bleis さん( @ )を呼ぶ時に「おい! イケメンッ! イケメンッ!」って叫んでるのがもの凄く怖かったです。日頃、You&I さんにパシらされてる bleis さんを想像させるような呼び方でした。

はじめてのグリーン車

  • 添乗員がちょろちょろしててウザかった。
  • なんかおしぼりもらえた。
  • やっぱり確実にコンセントを利用できるのはいい。
  • 席が広めでその分乗員を減らさなければならないんだしグリーン車分の料金は、まぁ、仕方がないのかなぁと。
  • でも、一番のグリーン車の良さはその値段の高さから乗客がフィルターされてその分マナーの悪い乗客が居て不愉快な思いする可能性が下がることなんじゃないかなぁと思ったり。

UQ WiFi & UQ WiMAX

  • UQ WiFi は駅では比較的まともだったけど、新幹線の中では接続が安定せずダメダメでした。
  • それよりエリア内であれば UQ WiMAX が新幹線の走行中であっても余裕で使えました。

  • 新MacBook Air やら kindle やら ブギーボード を見せてもらいました。本当、この手のイベントは新ガジェットを見せびらかしたい側とチェックしたい側の利害が一致してすばらしいですね。

2009-09-12

[] 部分的なマーク・アンド・スイープ( Partial Mark and Sweep )の詳細について

昨晩、Twitter上で、循環参照問題*1を機械的に排除する方法について意見を求めたところ id:DigitalGhost さん( @DecimalBloat )から...

http://wiki.livedoor.jp/author_nari/d/GC/extend/Partial%20Mark%20and%20Sweep

...というものをご紹介頂いたのですが、「4.scan」の記述が非常に残念な状態になっています。

で、今日、たまたま id:DigitalGhost さんと名古屋でお会いすることになっていたので、これ幸いと id:DigitalGhost さんからその詳細を教えて頂きました。その際のメモを以下に残しておきます。

あるべき挙動のモデル

表記
表記説明
S1,S2,S3スタックからの参照
A,B,C,D循環参照を形成しているオブジェクト群
X循環参照を形成しているオブジェクト群から参照されている外部のオブジェクト
吹き出しの数字それぞれのオブジェクトの被参照カウント
初期状態

f:id:wraith13:20090912220707p:image

スタックからの参照のひとつが切れるがまだ別のスタックからの参照が残っている状態

f:id:wraith13:20090912221159p:image

最後のスタックからの参照が切れる状態

f:id:wraith13:20090912221155p:image

循環参照オブジェクトが解放された状態

f:id:wraith13:20090912221146p:image

部分的なマーク・アンド・スイープ( Partial Mark and Sweep )での挙動

件のページと併せてご参照ください。

「4.scan」の記述が致命的なのは「4.scan」は実際には 「3. Mark Gray」と同様の「Mark Black」という操作と「whiten」操作をごっちゃに記述していることです。これらはそれぞれ...

Mark Black
Mark Gray と同様の操作を行なう。ただし非grayのオブジェクトをgrayに置き換えるのではなく、参照カウントが非0で且つgrayのオブジェクトをblackに置き換え、また参照カウントを -1 するのではなく代わりに +1 する。
Whiten
「Mark Black」を実施後、grayで且つ参照カウントが0のオブジェクトをwhiteにする。

...のようになります。*2


スタックからの参照のひとつが切れるがまだ別のスタックからの参照が残っている時の挙動

f:id:wraith13:20090912221159p:image:left

f:id:wraith13:20090912221435p:image


最後のスタックからの参照が切れた時の挙動

f:id:wraith13:20090912221155p:image:left

f:id:wraith13:20090912221430p:image


f:id:wraith13:20090912221146p:image

追記

微妙に解釈が間違っているようです。詳細はコメント欄を参照。

*1:スマートポインタを利用したシステムおいてプログラムからは一切アクセスされなくなったにも関わらず循環的に相互参照することで生き長らえてしまうオブジェクト群が発生する問題。リソースリークの一種。

*2:「Mark Black」も「Whiten」も便宜上そう勝手に呼称しているだけで正規のステップ名ではありません。

2009-07-30

[][][] 2009-08-30 開催の Future Language TV でスピーカーやります。

【Future Language TV のイベント情報】

予告無く大幅に内容を変更するかもしれませんが、現在、以下のような内容での発表を考えております。

lucifer の設計コンセプトと導入予定の機能について

  • 未来の言語の前に
    • これからのコンピューティングについて
  • 設計コンセプト
    • 一般論としてはどのような言語を設計するべきなのか。
    • lucifer としてはどのように設計するのか。
  • 導入予定の機能紹介
    • 完全演算表示 ( providence )
    • 超例外処理 ( super exception handling )
    • 連鎖参照 ( presenter )
    • 型復元/修飾復元 ( type restore / qualification restore )