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日でした。

まとめ

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

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-23

[][] オーナーメイド自分アイコン缶バッチ共同購入者の募集

面倒臭い思いするよりは多少お金を余分に払うほうがマシだと考えてるぐーたらさんなので、あまり本意ではないのですが缶バッチ共同購入を強く希望する人達も居られるようですし、気まぐれを起こしてたまには面倒なことをやってみます。

各種条件

発注先
ZEAMI Art ( http://www.zeamiart.com/ )
缶バッチの種類
円形25mm
個別包装
あり
一人あたりの注文個数
下記[共同購入者人数別の数量と代金]を参照
一人あたりの代金
下記[共同購入者人数別の数量と代金]と[購入費用内訳]を参照
応募方法
この記事のコメント欄もしくは、Twitter での @ あるいは D で私宛に [缶バッチ共同購入希望] と告げて下さい。( Twitter の D でご応募頂いた場合はその内容を第三者にお知らせすることはありません。) また、引き渡しの場所や時期になどについて相談がある場合は併せてその旨をお知らせください。
募集締め切り
2009-09-26(土曜日)のお昼ぐらい締め切りました。
最低応募人数
0人(誰もいなくても私一人で購入します。)
最大応募人数
5人(人数が増えるほど、私の手間もリスクも増えるだけなので)
応募者が多い場合
不公平に抽選で選びます(トラブルを避けたいので私との接点の多い人を優遇します)。 選ばれた方も選ばれなかった方も個別に2009-09-27(日曜日)までにその旨をお伝えします。
デザインの確認および調整期間
来週いっぱいぐらい?
発注
デザインの確認および調整が済んだらすぐ
道化師のところへの商品到着
発注から2週間後ぐらい
商品の引き渡し
極力、東京都内(山手線圏内)のどこかで代金と直接引き替え
商品の引き渡し期限
道化師のところへの商品到着後、極力1ヶ月以内でお願いします
引き渡し時の商品の包装状態
個別包装されている以外の包装は一切しません
その他
クレーム等は基本受け付けません(儲けもなく面倒を背負ってる状態なのでお許しを。しかし、私自身が重過失を犯したと認める場合にはそれなりに対処します。)

共同購入者人数別の数量と代金

人数数量代金
115\1,500
210\1,000
3--
46\600
55\500

...希望者が3人の場合、応募期間を1週間だけ延長します。延長しても3人のままだった場合、抽選で2人に絞ります。

購入費用内訳

項目数量単価合計
円形25mm缶バッチ30\40\1,200
個別包装オプション30\15\450
送料1\950\950
代引き手数料1\315\315
----
総計--\2,915

2009-07-30

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

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

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

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

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

2008-08-30

[][] わんくま同盟 横浜勉強会 #1 に行ってきました。

スピーカーの方々、スタッフの方々、お疲れ様でした。

以下、思ったことなど(中華街ツアー中の話の内容も含みます)...

template の欠点について
マクロとの対比をやった以上、マクロのように宣言されているかどうかをチェックできない点について触れて欲しかった。
shared_ptr の参照カウントのアロケートについて
高々 int ひとつとは言え、アロケートはコストが高い処理なので可能ならば避けるべきで shared_ptr で使うことが前提となるクラスでは、予め参照カウント(クラス)を継承しておけば外付けの参照カウントを使わないで済むとかそんなギミックを実装することも可能なハズなんだけど、実際の boost の実装ではどうなってるんだろう? ちなみにバグベアードで使ってるスマートポインタは参照カウントクラスの継承と外付けの両方にフレキシブルに対応しています。バグベアードのやり方では外付けの参照カウントを使うことになった際にターゲットのポイントを参照するのにひとつ余分に間接ポインタを介することになるというデメリットがありますが、この点についてはホルダー側にポインタをひとつ増やすことで解消可能です。
プリプロセス時にも有効な Borland の sizeof 云々の話
http://ml.tietew.jp/cppll/cppll/article/13290 ... Borland だとこーゆーアホなことができます。