5000164 is here
My writing is my life.
No results for undefined
Powered byAlgolia
合コンに参加してから落ち着かない心の平穏を取り戻すために

僭越ながら合コンに参加させていただきました

この度、ありがたいことにご縁がありまして、合コンに参加させていただきました。
合コンに参加するのは4ヶ月ぶり2度目になります。
それ以来、なかなかに心の中がもやもやと落ち着かないので、現在の心境などを言語化してみようと思います。
なにはともあれまずはこのような機会を与えていただいたことに感謝です。

内容については特筆しません

私が書こうとしていることは、合コンが終わってからの話なので、内容について特に触れません。
ただ、非常にありがたかったこと、非常に楽しかったこと、非常に魅力的であったことはここに記します。

合コンが終わってから心が落ち着かない

なんだか心がフワフワしています。
慣れないことをしたからかも知れません。
合コンのことを思い返したり、他の女性のことを考えたり。
なんだか女性のことばかりを考えてしまいます。

初めて合コンに参加した時も舞い上がった

初めて合コンに参加したのは今年の初めのことですが、その時も合コンが終わった後は不安に駆られました。
合コンがあまりに楽しすぎて、これからの人生のバランスが取れるのだろうかと。
でもその不安は家でプログラミングをしている時に解消されました。
プログラミング超楽しい、合コン以外のこともちゃんと楽しむことができると。

そもそもなんのために合コンに参加したのか

今回心が落ち着かない最大の原因はここにあるような気がします。
私はなんのために合コンに参加したのか。
回避しようと思えば回避することはできた。
ではなぜ自らの意志で参加したのか。
それは、楽しそうだったから。

楽しむことはできたのか

大いに楽しむことができた。
プログラミングや、普段友達と遊ぶ楽しさとは、また異なったベクトルでの楽しさを感じた。

楽しめればそれで良かったのではないか

たしかに、楽しかった、で終われば何も問題はない。
しかし、今現在悩んでいるということは、楽しかった以外の何かがあるということになる。

楽しい以上の何かを求めてしまった可能性

私は、もしかしたら、楽しい以上の何かを求めてしまっていたのかも知れない。
その楽しい以上の何かがなんなのかはわからないが、楽しい以上の何かを求めて、それが得られなかったとするならば、満たされない想いに悩んでいるということは考えられる。

仏教にも、見るから執着が生まれる、という教えがあった

対象を見ると心が動かされる。
実際に女性を目にすることによって、欲した心があったのではないか。
知るから執着する。
執着するから苦しむ。

承認欲求がバシバシ満たされていく

合コンでは承認欲求がバシバシ満たされて、リアルに「僕はここにいてもいいんだ」状態になる。

女性と会話しているという事実

女性に慣れていない私は、女性と会話するだけで緊張します。
うまく話せません。
女性を特別視しすぎてしまうという問題を抱えています。

下賎な話で申し訳ないですが

正直なところ、女性との身体的接触を喜ぶところはあります。
今回は肩が当たった時なんかに、喜ばしい感情を抱いてしまった。
ちょっと接触したりなんかすると、すげー緊張して頭のネジが吹っ飛ぶ感じ。
これに関しては本当に申し訳ない。
そしていろいろ考えてしまったのもまた事実で、本当に申し開きのしようもない。
自分は本当にクズだなぁと悔やむことしきりです。

上記のことをまとめると

要は、調子に乗ってる状態になる。
そして、調子に乗って途方もない欲求を抱える。
でも、その欲求が満たされることはない。
つまり、理想と現実のギャップに苦しむ。
ここでは、このギャップこそがもやもやの原因だと結論付ける。

もやもやを解消して心の平穏を取り戻すために

調子に乗って、大きな欲求を抱えていたことを自認する。
それは間違いであったと受け入れる。
深呼吸する。

簡単な原因まとめ

具体的な目標を決めずに臨んだことがよくない。
女性を見ることによって心に執着が生まれてしまった。

簡単な対策まとめ

具体的な目標を決める。
目に入ったもの全てを欲しがるのではなく、求めているものと求めていないものをしっかり区別する。
もしくは、最初から目に入らないようにする。
もしくは、このもやもやを含めて楽しむ。
とりあえず、調子に乗りすぎると暴発するのでそこは本当に気をつける。

まとめ

合コンは非常に楽しいものですが、それで苦しんでいたら本末転倒。
用法用量を守って正しく合コンしましょう。

ブログ移転しました

WordPressからOctopressへ

タイトルにもありますが、ブログを移転しました。
ブログの管理をWordPressからOctopressへ変えました。

WordPressからOctopressへ変えた理由

一番の理由としては、サーバーに公開するのが静的ファイルである、という点です。
速さという面でもセキュリティという面でも有利だと判断しました。

5000164.jpからblog.5000164.jpへ

ついでにドメインも変えました。
最初は5000164.jpを私のブログのドメインとして位置づけていたのですが、5000164.jpを私のドメインとして、それに付随する形でブログのドメインを作りたいと思ったのがきっかけでした。
ドメインを変更するとそれなりに影響が出るのですが、そのあたりはせっかくの機会なので勉強したいと思います。

Windows 7からUbuntu 14へ

普段からWindowsには不満を持っていたのですが、今回Octopressをインストールする際にどうせだからUbuntuに移行してしまえ、と思ってメインOSを変えました。
やはりUbuntuの方がWindowsよりも開発しやすい環境ですね。

これから

まずはOctopressに慣れるようにします。
移行した際に調べたことなどを記事にしていく予定です。
これからもよろしくお願いします。

DXライブラリで読み込んだテキストをエンターで表示

実行結果

これが。

こうなって。

こうなってって。

最終的にはこうなります。

正直こんなに長くする必要はなかった。

ソースコードはこちら。

5000164/dxlib-practice-2

ゲームなんだから入力できるようにしなくては

前回 はDXライブラリで文字を表示するだけでしたが、こんどは入力を受け付けるようにします。

とりあえずエンターキーを押したら単純に表示するだけ。

表示するテキストをファイルから読み込むようにした

ついでに、表示するテキストを外部から読み込んでいます。

最初はUTF-8でテキストを書いていたら、文字化けをしてうまく読み込めません。

DXライブラリはShift_JISとCRLFで書かれているので、テキストもShift_JISとCRLFで書いたらうまくいきました。

プロジェクト全体の設定も、DXライブラリに合わせてShift_JISとCRLFで統一するのがいいと思います。

個人的にはUTF-8のLFが安心するのですが、DXライブラリを使っている時点で動作する環境はかなり限られるので、特に問題はないかと思います。

まとめ

こんなに簡単な処理なのに、結構時間がかかりました。

やはり基礎的な知識がないと、どうすればいいのかわからないということが多いですね。

変えられないエンジニア

「君は変えられるエンジニアか?変えられないエンジニアか?」

下記リンクから引用

PHPerのためのJenkins | アライドアーキテクツ エンジニアブログ

私は変えられないエンジニアだった。
そして逃げ出してしまった。
逃げ出した判断は間違っていなかったと今でも思う。
ただ、何も変えられなかったことを後悔している。
今でも、中途半端に干渉しては無力感を感じている。

私はなぜ変えられないエンジニアだったのか

原因がわからなければ対策もできない。
全員が必ず変えられるエンジニアになる必要はないが、私は変えられるエンジニアになりたい。
そのために変えられなかった原因を考える。

自分では「良い」と思ってるこの「良さ」を共有できていない

改善はなぜ存在するのか。
そこに問題があるからである。
問題からストレスが生まれ、このストレスを消すために改善する。
この「ストレスを消す」ことが良さである。
しかし、ストレスが共有できなかった。
ストレスが共有できなければ、消すもなにもない。
はじめから存在しないのだ。
改善するためには、ストレスを共有しなければならない。
ストレスを共有するためには、より良い状態を提示するしかない。

結果が出ていないのに周りを巻き込んだ

より良い状態を提示できないまま、周りに改善を強要した。
ストレスを感じていない状態では、解消するストレスも存在しないので理解してもらえない。
当然の結果である。
人は損得勘定で動く。
私はストレスを消せるなら得すると思って動いた。
存在しないストレスを解消するのは、コストだけかかりメリットがない。
損すると思ったら誰も動かない。

問題の共有ができなかった

この1点につきる。
ここをもっと突き詰められていれば、結果はもう少し変わっていたかも知れない。

改善を共有するのではなく、問題を共有すれば、自ずと改善に向かう

自分の中で「悪い」と感じていることが、他人の中では「悪くない」ということは往々にして起こりうる。
その時に大事なことは、自分の悪いを改善するための行動を共有するのではなく、悪いを共有するのである。
悪いが共有できたら、あとは一緒に改善していける。

問題を共有して改善するために、まずは改善結果を出す

では問題を共有するためにはどうすればいいのか。

最も説得力があるものは、改善結果を提示することである。

まずは自分が改善する。

そして結果を作る。

結果からどこが悪くて、改善するとどうなるのか示す。

早まってはいけない。

共有するのは結果を出したあとだ。

結果を出したら隣の人から巻き込む

まずは隣の人から巻き込もう。
隣の人とも共有できない問題であるならば、全員と共有できるはずがない。
とにかく1番近くの人に話してみよう。
人目をはばかるなら直接ではなくてもいい。
大事なことは問題を理解してもらうことである。

近くの人から幸せにする

考えだした改善策は、実行した人を幸せにするものか?
その幸せを共有したいと思えるか?
幸せを共有したいなら近くの人からだ。
隣の人を幸せにできたなら、次は反対隣の人だ。
次は正面の人。
急いてはいけない。

変えられるエンジニアに意味はあるのか?

環境を移せばいいだけではないのか?
たしかにそれもある。
だが、誰かを幸せにできるならそこに意味はある。

DXライブラリできれいなフォントを表示する

早速見ていただきましょう

ソースコードはこちら。

5000164/dxlib-practice-1

DXライブラリで1番最初に確認したのがフォントの表示

ゲームのようなものを作りたいなと考えていて、知人に教えてもらったDXライブラリを使うことにしました。

DXライブラリ置き場 HOME

その際に、1番初めに確認したことがフォントの表示でした。

フォントの美しさはモチベーションに直結します。

結果はごらんの通り

美しいフォントを表示させることができました。

ちなみに比較対象として、デフォルト設定でのフォントを下部に表示しています。

フォントをきれいに表示するには1行追加するだけ

ChangeFontType(DX_FONTTYPE_ANTIALIASING_8X8);

この文を追加するだけです。

この文を追加することでフォントにアンチエイリアスをかけてくれます。

DXライブラリ置き場 リファレンスページ

よりうつくしい表示のために若干の影をつけています

アンチエイリアスをかけるだけで十分きれいに表示されます。

ですが、ここではよりフォントを際立たせるために、若干の影をつけています。

まずは背景に影を描画。

フォントを描画したあとにガウシアンフィルタをかけるのがポイント。

// 影の表示開始位置
text_x = font_size + shadow_offset_x;
text_y = font_size + shadow_offset_y;

// 影のベースとなる文字列を描画
for (int row = 0; row < 5; row++)
{
DrawString(text_x, (int)(text_y + ((font_size * line_height) * row)), text[row], shadow_color_dx);
}

// ガウスフィルターを施して影にする
GraphFilter(backscreen, DX_GRAPH_FILTER_GAUSS, 8, 50);

背景ができたら、普通にフォントを描画します。

// テキスト表示開始位置
text_x = font_size;
text_y = font_size;

// 文字列の描画
for (int row = 0; row < 5; row++)
{
DrawString(text_x, (int)(text_y + ((font_size * line_height) * row)), text[row], font_color_dx);
}

これで完成です。

まとめ

もちろん処理の負荷が高くなるとのことですが、美しいフォントの表示が可能であると知れて満足です。

WPF で方向キーを入力した方向へ四角形を動かす

実際に作ったものはこんな感じです

方向キーの入力した方向へで赤い点が動きます。
ソースコードはこちら。

画面に動かすものを表示する

とりあえずなんでもよかったので、 Rectangle タグで四角形を表示します。
そして、位置を指定するために Canvas タグで囲みます。

<Canvas>
    <Rectangle Name="pointer" Width="10" Height="10" Fill="Red" Canvas.Left="0" Canvas.Top="0" />
</Canvas>

これで XAML 側はほぼ完成。
あとは動かすだけ。

キーボードの入力を取得します

Window に PreviewKeyDown をつけます。
これでキーが押されたらイベントが発生します。

C# 側で座標を取得するために

まずは四角に Name をつけます。
これで C# 側で変数として扱えます。

四角の現在位置を取得する

C# 側で四角につけた名前から座標を取得します。

// 現在地を取得
Double leftPosition = Canvas.GetLeft(this.pointer);
Double topPosition = Canvas.GetTop(this.pointer);

入力されたキーの内容を判断する

次は、方向キーが入力された方向へ動くために、入力されたキーを判断します。

// 入力された方向キーの方向へ移動
if (e.Key == Key.Up)
    // 上
else if (e.Key == Key.Down)
    // 下
else if (e.Key == Key.Left)
    // 左
else if (e.Key == Key.Right)
    // 右

入力された方向へ移動する

入力された方向がわかったら、その方向へ座標を移動して this.pointer にセットします。

// 入力された方向キーの方向へ移動
if (e.Key == Key.Up)
    Canvas.SetTop(this.pointer, topPosition - 10);
else if (e.Key == Key.Down)
    Canvas.SetTop(this.pointer, topPosition + 10);
else if (e.Key == Key.Left)
    Canvas.SetLeft(this.pointer, leftPosition - 10);
else if (e.Key == Key.Right)
    Canvas.SetLeft(this.pointer, leftPosition + 10);

完成

これで、キーボードの方向キーを入力した方向へ移動することができました。
ただ、ゲームのようなものを作ろうと思っていたのですが、これだと実装が大変そうです。
他の方法も調べてみようと思います。

WPF で枠のないウィンドウを作る

実際に作ったものはこんな感じです

ソースコードはこちら。

実装するにあたって参考にしたサイト

こちらの記事を参考にさせていただきました。

この記事に沿っていったらできました。
これを追記するだけ。

<WindowChrome.WindowChrome>
    <WindowChrome CaptionHeight="23" ResizeBorderThickness="100" />
</WindowChrome.WindowChrome>

枠なしには出来たけどウィンドウの影が気になる

ウィンドウの枠がなくなってかっこよくなったのに、影が主張し過ぎで気になります。
この影も消したい。
影を消す方法を調べていたら、先ほどと同じブログのこちらの記事にたどり着きました。

なるほど、よくわからん。
WPF初心者の私には無理だと判断したので、この記事の冒頭で紹介されていた簡易版で実装します。

影をいい感じにつける

<Window x:Class="練習1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow"
        Width="700"
        Height="700"
        WindowStyle="None"
        AllowsTransparency="True"
        WindowStartupLocation="CenterScreen"
        Background="Transparent">
~中略~
    <Border BorderBrush="#222222" Background="#222222" BorderThickness="1" Margin="100">
        <Border.Effect>
            <DropShadowEffect ShadowDepth="0" BlurRadius="100" Color="#000000" Opacity="0.7" />
        </Border.Effect>
~中略~
    </Border>
</Window>

Window に WindowStyle="None"AllowsTransparency="True"Background="Transparent" を指定することで、枠を消して透明にしています。
アプリが描画できる範囲が Window の 700 x 700 の内側のみで、その内側にさらに影とウィンドウを描画する、という認識です。
内側の Border に Margin を設けて、影をつけています。

WindowStyle="None"だと移動やリサイズができない

しかし、この方法だと移動がリサイズができなくなるらしいです。
こちらの記事などで、 WindowStyle="None" を使用した時の対策が書かれていました。

よくわからない、できればやりたくない。
と思っていたら、前述の WindowChrome のおかげか、特に何もせずに移動もリサイズもできました。

よくわからないけど動いたので完成

というわけで、枠なしのウィンドウを作りたい、という目的は達成しました。
ただ、ウィンドウの影はOS側に任せるべき処理であって、アプリ側でいじるべきではないと感じました。

4ヶ月無職で過ごした感想

私は無職で約4ヶ月間過ごしました

せっかく無職で4ヶ月も過ごしたので、その感想を書いてみたいと思います。

あんまりこういう機会もないことですし。

最初は不安で仕方がなかった

辞めて最初のうちは不安でした。

不安で不安で、早くなんとかしなきゃとずっと思っていました。

そうしたらすごく疲れました。

不安ばっかりなのはよくないです。

なるべく気楽に考えるようにしてたらすごい楽しくなってきた

すごい疲れてしまったので、なるべく気楽に考えるようにしました。

大丈夫なんとかなるさ、と。

気楽に気楽に考えていたら、すごい楽しくなってきました。

お金こそあんまり使えないものの時間がたくさんある。

開発したいときに開発したり、麻雀したい時に麻雀したり。

気分が乗ったら好きなだけ好きなことできるのはすごい楽しかった。

物事を楽しく感じる気持ちの余裕を持ち続けることが大事ですね。

そして1番びっくりしたのがたくさん助けがあること

仕事は自分で見つけるしかないと思ってましたけど、そうでもないんですね。

「こういう仕事があるらしいよ」「ここで求人募集してるってよ」

というような連絡を5, 6人以上の方からいただきました。

この友達の少ないおれが。

すごいびっくりしました。

そしてなによりありがたかった。

すごい嬉しかったです。

あとはすごい心配してもらえる

みんないい人なんです。

無職だっていうと心配してもらえて相談に乗ってもらえます。

すごくありがたいです。

そして仕事が決まるとすごい喜んでもらえる

おめでとうと言われると、自分のことのように嬉しくなります。

自分のことだけど。

喜んでもらえるのが嬉しいですね。

これもほんとにありがたい。

結論:ありがたい

ほんとに感謝です。

とても嬉しくなります。

ほんとにありがとうございます。

まとめ:なんとかなる

無職になったときはとても不安だったけど、なんとかなるものだと思いました。

あんまり物事を不安にばかり捉えないで、気楽にいくのも大事です。

その方が人生楽しい。

プレゼンは想いを伝える手段 - 本の感想(プレゼンテーションzen/ガー・レイノルズ、熊谷小百合訳)

そのプレゼンはなんのため?

つまらないプレゼンが溢れかえっている。

資料をただ読み上げるだけ?

やらされてやる?

そういった悲劇をなくすためにはどうすればいいのか。

プレゼンとは、伝えたい想いがあり、聞き手を説得するために行う手段の1つである。

プレゼンの見せ方

スライドはドキュメントではない。

主役はスライドではなく発表者である。

スライドは引き立て役。

発表者を引き立てるためにはどんなスライドがいいのか。

デザインの知識がなくてもわかりやすいように書いてある。

プレゼンについての全般的なことをわかりやすく教えてくれる

なんのためにプレゼンをするのか。

その準備から発表の心構えまで。

想いを伝える方法や資料をデザインする方法まで簡潔にまとめられていてわかりやすい。

プレゼンの資料がたくさん載ってるのも参考になっていい。

プレゼンがうまくなるためには、いいプレゼンを知っていること、伝えたい想いを持つこと、そして練習が大事ですね。

使いやすさとはなにか - 本の感想(誰のためのデザイン?/D.A.ノーマン、野島久雄訳)

非常にわかりやすかった

具体的な例が多く出てきて非常にわかりやすかった。

使いやすいデザインとはなにか。

どのようなデザインが使いにくいのか。

どのようにデザインすれば使いやすくなるのか。

読むのに半年くらいかかった

読み始めるのにそれほど抵抗はないのだけれど、読み進めるのが遅かった。

事前に読みやすい読みやすいという評判を聞いていたせいで、私が誤ったメンタルモデルを構築してしまったのかも知れない。

ユーザーよりも開発者を優先したことがある

なにかを作る時に、「作るのが簡単だから」という理由で決定したことがある。

もちろん開発工数を抑えることは大事だけれど、それで安物買いの銭失いになってしまっては本末転倒である。

デザインをもっと考えるべきであった。

わかりやすさよりも見た目の簡単さを優先したことがある

具体例としても出てきたボタンの配置について、なんとなくすべてを同じ形にしてしまったことがある。

持っている機能が違うのに同じ見た目ではわかりづらい。

1つだけ色がついていたらかっこ悪い、1つだけ形が違っていたらダサい、という「なんとなく」で決定してしまった。

ボタンにも同じ形なら同じ形であることの意味を考えるべきである。

もっと使いやすさについて学んでいきたい

読むのに時間はかかったが非常にためになる本だった。

私がこの本で特に気に入ったのはこの一文。

さて、これからはあなたの番である。もしもあなたがデザイナーならば、使いやすさを目指す戦いに加わってほしい。

「誰のためのデザイン?」P.358より

使いやすさというものについてもっと学んでいきたい。

使いやすさを目指す戦いに加わらなければならない。

もし、使いやすさに興味があるのなら一読をおすすめします。

最後に、この本からのメッセージを。

そして、あなた自身にも楽しんでもらいたい。デザインの細かなところまで確かめながら世界中を歩きまわって欲しい。役に立つようなものがあれば、小さなものでもうれしく思ってほしい。そのようなものを慎重に考えて組み入れた人を好意的に考えてあげてほしい。そして、そのような細かいことが重要なのであり、そんな小さなことのためにも、デザイナーは役立つものを組み入れるべく力を尽くさなければならなかったにちがいないということをわかってほしい。よいデザインをもたらしてくれた人には、心の中で賞を贈ろう。花も贈ろう。よいデザインをしてくれなかった人には、きびしい批判をしよう。その人には雑草で十分である。

「誰のためのデザイン?」P.358-359より