「プラクティス」を含む日記 RSS

はてなキーワード: プラクティスとは

2017-04-21

IT】画面遷移図のベストプラクティスがわからない

ちなみに俺はモバイルアプリ開発者

 

どの画面遷移図を見ても、わかりづらいと感じる

わかりやすい画面遷移図を見たことがない

 

最近モックアップツールもいっぱいあるが、モックアップはそもそも俯瞰できないか意味がない

モックアップツールの吐き出す画面遷移図はもう破滅的だ 

 

画面遷移図がスッキリしていると、ユーザー側も理解やすいのは確かだが

込み入ってるからわかりづらいとは、確定的には言えないと思う(経験的には分かりづらいことが多いが)

 

結局、開発者ユーザーに対して適した量のviewだけを見せている

例えば、コンテンツ、前に戻る、次に進む、より一覧の階層、より詳細の階層、別の要素など

あるコンテンツ関係的が近しいviewを表示している

あるいはそれに至る導線を示している

実際には全体が非常に複雑でも、そういう風に表示すると人間理解やすいから、そうしているのだ

 

逆に言えば、元の複雑な状態を見せられたら、そりゃー分かりづらい

分かりやすかったらwebアプリもいらない、まるごとユーザーに示せばいい、開発なんて誰でもできる、でもそうではない

 

 

じゃあどうやって画面遷移図を作ればいいのか

画面遷移図は分かりづらいが、分かりやすく見えるように全体を設計することは可能

俯瞰でみた時にわかやすい」というのは、細部を見る必要が無いくらいに脳内モデル化できるということだ

日本地図を見ても、世界地図を見ても、町内地図を見ても、「わかりやすさ」は変わらないのと同じだ

 

からフラクタル構造みたいに、階層的にモデル化された構造を取っていれば見やすくなると思う

そうした時に良い形の画面遷移図は、大きなモデルからさなモデルへ辿れるようなUIになっているか

あるいは大きなモデルと小さなモデルを両方見ることができて、ただどちらに注目するかで見え方が異なるような状態になっていればいいと思う

 

 

ここまではわかるが、このあとはわからない

デザイナーの方、何かいい感じのやつお願いしま

 

2017-01-05

Facebookまとめサイトシェアちゃう人を見ると

どう反応していいか困るよね

あの触れづらい感じ…

半年ROMってろって言うのがベストプラクティス

2016-12-29

はてブで「Amazon」と検索してみると

昨今話題になってるヤマト佐川関連のブックマークが上位を占めるかと思いきや、まったく違った。



2016年12月29日10:54時点、本文、新着順で検索

Amazon検索結果 (絞り込み: 3 users 以上) 約 3,423 件中 1 - 40 件目 (0.26 秒)


以下略



ECサイト連想させるトピックほとんどなくて、AmazonB2B向けサービスを充実させていることに驚いた。

Amazonって表向きは物流業界革命問題を起こしている要因に挙げられているけど、EC以外のインパクトがどれだけ大きいのか門外漢なので分からない。

↑でブクマ付けた人、何が起きるのか教えて

2016-11-28

陰毛を刈りたい

でも髪の毛用のバリカンはでかくて手入れ大変だし、ごついかコントロールが大変

何がいいんだろう

眉毛バリカン鼻毛バリカン

デリケートなところに向いてるって意味では後者かなあ

でも面積の広さ考えると効率は悪そう

何がベストプラクティスなんだろうか

2016-11-02

Wantedlyのジレンマ

Wantedlyを使って転職すると、採用担当マメな人ならWantedly上でその会社メンバーに追加してくれる。

そうすると同じ会社メンバープロフィールがお互いに見られるようになるんだけど、最近また転職したくなってきてちょっと困ったことがある。

転職向けにプロフィールを充実させようとは思うんだけど、その動きって他の社員にも見えるので、要は辞めようとしてるのがバレてしまうのではないか、と懸念しているのだ。

そういうものだと開き直るか、あるいは応募者向けに情報を充実させるという体で動くのもアリかもしれないけれど、それでもどこか抵抗感がある。

Wantedlyで複数回転職した人にベストプラクティスを聞きたい。

2016-09-23

残暑という夏の名残が秋の長雨に流されていっても、晴れることがない気持ちを抱えながら「蛍火の杜へ」を見ていた。

艦これ川内にそっくりなおてんば娘の蛍が出てきて、映画早々にお茶が喉に詰まった。エンドクレジットでやっぱり同じ人が声を当てていた。

手がつけられないあの時分特有闊達さがはしゃぎ回る黄色い声に出ていて、それだけで消えたくなる。

夏休みの宿題に全く手をつけてなかったが、子供達はちゃんと宿題を終えただろうか。

夏だけの逢瀬という縛りを破って距離感を一気に縮めたら消えて無くなるのは、まるで長続きしないバッドプラクティス夫婦みたいだ。

身にしみて辛い。



蛍は夏の夜の盛りにしか光らない。夜の帳に涼しさと共に光る淡い旋律

真冬コタツからあの淡い光を思い出そうとしてもうまく描けまい。

ギンと蛍の10回の夏もしばらくそんな感じなんだろうな。

ギンがいなくなった後、蛍はギンの住んでいた山神様妖怪の山にほど近い山里で、

新しい仕事に新しく寄り添う人を見つけてまた夏が巡りますように。

2016-07-11

アジャイルの害

アジャイルプラクティスマイクロマネジメント的なものが多い。


これらのプラクティスを,アジャイル文化であり精神であるところの「自律」なしに導入したらどうなるか。
 日本管理職マイクロマネジメント好きと相まって,地獄のようになるのは想像に難くない。

からエモいと言われようがなんだろうが,アジャイルはその文化精神理解なしに導入してはいけないのだと思う。
 アジャイル手法のように扱い,アジャイルプラクティスだけをあたかも「アジャイルであるかのように勧めるコンサルタントトレーナー危険まりない。

CICDのようなマネジメントにあまり関係のないものを,「アジャイル手法」ではなく,単に業務効率化の方法として取り入れるのはありかもしれない)

2016-05-25

visudoユーザーsudo権を付与する方法

visudo検索すると上位の記事


user_name  ALL=(ALL) ALL

みたいに直接書き加えるって書いてあるけど、

%sudo  ALL=(ALL:ALL) ALL

がなければ追加して

usermod -aG sudo user_name

とか、Debian系なら

adduser user_name sudo

なりでグループ所属させる方がいいよね。こういうバッドプラクティスたち早く検索上位から駆逐されて欲しい。

2016-05-02

最近スパムNGワード

もう「http://」を登録してリンクは全部弾いちゃったほうが良い?

あ、トラバ消えてまうわ

どうすりゃええのん? ベストプラクティス求む!

2016-04-21

転職は5年勤めてから

の方が良い。

後悔しかしませんよ

追記 :

プログラミング技術はある程度自分で調べればわかるから設計ベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。

まぁ、結構勉強になったから良しとする。

追記 : 2015/08/12

社内勉強会を定期的にやってる。今日分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。

てか思った。そもそも、傾向分析する必要あんの?減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね?以下の例がうちの会社がやってること。

会員数が減った → 退会した会員の様々な傾向を分析しよう!

これはマジであん意味ない。今日の勉強会の答えは

具体的な原因を突き止めてそれらの傾向を分析する的な感じ。

でもそんなのめんどくさくね?

俺の考えは以下。

会員数が減った → SEOを強化(減った数以上に増やす)。そんなチマチマした改善工数かけんなら新しい機能新規事業を行う。

つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。

っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね

追記 : 2015/08/14

憂鬱でなければ仕事じゃない」

それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう?僕が考えた結果

「モノを実現するための話し合い」

時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな?要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議夢物語を語る場だから会社楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない

追記 : 2015/08/19

会議議事録重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事スムーズにいく。延びる会社ってのはホワイトボードが多いしなー。

あとxamarinの発表。プレゼンの下手さに感動。

ほとんどライブラリ使えるの?とか知らねーよ、だいたい使えるわ。UI共通化は?出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな!みんなモチベ低い!

ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ!!周知しよ、難癖つけられそう笑

追記 : 2015/08/22

すごく重要な話があった。すごく憂鬱になる話。

でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。

よく技術者営業対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。

営業キツイよなー、成果出なきゃやり甲斐が生まれないでしょ。

もう、みんなプログラミングやろ!楽しいよ!多分

追記 : 2015/08/24

空気が重い。卒論思い出す。

いろいろ考えるから憂鬱な話はあとに効くみたい。

この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。

「一生面倒みる覚悟がないなら助けるな」

大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。

追記 : 2015/08/26

面談。褒められた。評価評価うるせぇ。評価給料からあんま興味ねーよそこには。給料転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身経営者がいる会社に入りたかったなほんとに。

っかangularjsすごいいいなと。双方向データバインディングHTML拡張フロントと完全分離出来るのがあつい。

追記:2015/09/07

夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱会社まり

僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい(近々、エグいの書く)。まぁ、回避たか問題ないけどさ。

追記:2015/09/16

ちょー出世した。事業責任者的な感じ。給料めっちゃあがる。転職して半年プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときゴリ押し回避方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。

これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。

追記:2015/09/30

今日、いろいろ発表された。なんか抜擢されたかおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手(俺も)。ちょっとガッカリ自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代スーパーエリートばかりなのになんかおかしいと思った。

もうasp mvc飽きたなー。angular楽しいからまだいいけど。

最近rails楽しいちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ!但し、サイトいつ出来るかなー。

追記:2015/10/15

やっぱ感情的な人はあんまりきじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議

っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかん人間的におかしくなるね。

追記:2015/10/19

いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ調子乗ってたら激安家賃の家にすまねーだろぅがよぅ!

って感じで愚痴はこれまで。

つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラム本質を突いていてjs馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。

追記:2015/12/07

好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。

追記:2016/02/11

小学生の頃と悩みが同じ。希望が持てた一年前の方がずっとマシだ

転職は5年勤めてから

の方が良い。

後悔しかしませんよ

追記 :

プログラミング技術はある程度自分で調べればわかるから設計ベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。

まぁ、結構勉強になったから良しとする。

追記 : 2015/08/12

社内勉強会を定期的にやってる。今日分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。

てか思った。そもそも、傾向分析する必要あんの?減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね?以下の例がうちの会社がやってること。

会員数が減った → 退会した会員の様々な傾向を分析しよう!

これはマジであん意味ない。今日の勉強会の答えは

具体的な原因を突き止めてそれらの傾向を分析する的な感じ。

でもそんなのめんどくさくね?

俺の考えは以下。

会員数が減った → SEOを強化(減った数以上に増やす)。そんなチマチマした改善工数かけんなら新しい機能新規事業を行う。

つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。

っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね

追記 : 2015/08/14

憂鬱でなければ仕事じゃない」

それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう?僕が考えた結果

「モノを実現するための話し合い」

時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな?要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議夢物語を語る場だから会社楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない

追記 : 2015/08/19

会議議事録重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事スムーズにいく。延びる会社ってのはホワイトボードが多いしなー。

あとxamarinの発表。プレゼンの下手さに感動。

ほとんどライブラリ使えるの?とか知らねーよ、だいたい使えるわ。UI共通化は?出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな!みんなモチベ低い!

ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ!!周知しよ、難癖つけられそう笑

追記 : 2015/08/22

すごく重要な話があった。すごく憂鬱になる話。

でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。

よく技術者営業対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。

営業キツイよなー、成果出なきゃやり甲斐が生まれないでしょ。

もう、みんなプログラミングやろ!楽しいよ!多分

追記 : 2015/08/24

空気が重い。卒論思い出す。

いろいろ考えるから憂鬱な話はあとに効くみたい。

この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。

「一生面倒みる覚悟がないなら助けるな」

大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。

追記 : 2015/08/26

面談。褒められた。評価評価うるせぇ。評価給料からあんま興味ねーよそこには。給料転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身経営者がいる会社に入りたかったなほんとに。

っかangularjsすごいいいなと。双方向データバインディングHTML拡張フロントと完全分離出来るのがあつい。

追記:2015/09/07

夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱会社まり

僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい(近々、エグいの書く)。まぁ、回避たか問題ないけどさ。

追記:2015/09/16

ちょー出世した。事業責任者的な感じ。給料めっちゃあがる。転職して半年プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときゴリ押し回避方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。

これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。

追記:2015/09/30

今日、いろいろ発表された。なんか抜擢されたかおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手(俺も)。ちょっとガッカリ自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代スーパーエリートばかりなのになんかおかしいと思った。

もうasp mvc飽きたなー。angular楽しいからまだいいけど。

最近rails楽しいちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ!但し、サイトいつ出来るかなー。

追記:2015/10/15

やっぱ感情的な人はあんまりきじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議

っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかん人間的におかしくなるね。

追記:2015/10/19

いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ調子乗ってたら激安家賃の家にすまねーだろぅがよぅ!

って感じで愚痴はこれまで。

つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラム本質を突いていてjs馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。

追記:2015/12/07

好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。

追記:2016/02/11

小学生の頃と悩みが同じ。希望が持てた一年前の方がずっとマシだ

2015-12-25

ベストプラクティスで生きていく必要はない

人生を豊かにする5つの方法」という中身のない記事を読むだけで満足する生活を送ってしまうのも、「エンジニアなら知っておくべき10個の知識」みたいなQiita記事ストックするだけで読みもしないで終わってしまうのも、「この5冊だけは読んでおけ」みたいな書評ブログ記事に「よさそう」とだけコメントしてそのままにしてしまうのも、全部ベストプラクティスで生きていこうとするからだ。

人生ベストプラクティスはないよ。お前がベストだと信じる、お前の人生ベストだ。










多分。

2015-11-17

エモさを楽しむ

映画などのエンタメに対して「泣ける」「感動」といった表現をするのははよくない。

何か素晴らしいもののように受け取る人が現れる。それに反発する人も出てくる。

そうじゃない。エンタメもっと即物的なものだ。

エモい」と表現しよう。「ブヒれる」と同レベルの、エンタメのただの一系統として扱おう。

どんどん茶化していこう。エモいのは決して高尚さを表さない。視聴者感情を揺さぶベストプラクティスしかない。

それを把握した上で釣られよう。感情を揺さぶられることをインスタントに楽しもう。

2015-09-08

フレキシブルなチームを目指す場合に、最も必要なのは、チームを停滞させないこと。

世にあるなんちゃら開発の殆どは、この状況を未然に防ぐため、予防的なプラクティス提案する。

ぶっちゃけ、停滞しないチームは進み続けるので、後は仕事量の問題です。と、だいたいごまかされるのが本のお決まり

停滞の原因はいくつかある。ぱっと思いつくのは

萎縮。

プロジェクトメンバーが萎縮してる状態で、個々への責任が超えてる状態。

これはミスや失敗が発生した場合に、本人が責任を追っている思い込みすぎているか。か、過度に個人の責任に追わせている。

比較的、分かりやすいのが特徴だが、責任塩梅という対処の難しさから放置されやすい。



無関心。見抜くのが難しい。

一見チームは滞りなく進んでいるように見えて穏やかに死に向かってる場合が多い。

外部刺激によって改善されるいことが多いが、これも力の塩梅によっては反発やさらなる無関心を呼ぶ



予防的なプラクティスと書いたが、それと同時に改善にも効果的なモノが多い。

朝会は、よくわからずに実行しても効果が出るのでお勧め



朝会は、単なる進捗共有会だと利用されてしまうことが多いが

本来は、朝会の効果は、リズムを作り上げること。

チームの信頼関係が弱い場合、そのリズムを共有することで信頼関係を築く。

さらに、個々のメンバーリズムおかし場合、それをリセットする場にもなる。

これが本来の朝回の効果



リズムが出来ることで、委縮と無関心は、自然改善されることが多い。

大切なのはリズムを作り上げようという考え方

2015-08-22

SEことば

SEの私の言葉意味

追記歓迎

言葉 意味
議事録 気が変わる前の意見
非機能要件 実装するかは気分次第
確認しておきます 今日は帰ります
オブジェクト指向 オ○ニー
偉い人の意見 パルプンテ
ちょっとした仕様変更 ザキ
客先担当者の急な交代 ザラキ
要件定義から見直し ザラキーマ
確定した仕様 幻想
WBS Sはサグラダファミリア
キーマン 鬱病になりにくいことがわかってる人
ベストプラクティス モジュール化されてません
増員 導入教育で作業が止まる
それは新しい方法ですね 問題がおきたらお前が対応しろ
操作手順書 唯一多少参考になる設計ドキュメント
備考 最も重要考慮事項
XXはリスク 問題が起きる(起きてる)けど俺は知りません
試験エビデンス 誰も見ないけど一番手間のかかるもの
ペアコーディング 今日だるいから流すわ
すべての入力パターンを網羅したテスト 1ケース0.1秒で実行しても宇宙が終わるほうが早い
フレームワークバグ 仕様です
カバレッジ100% 不具合だらけですがコンパイルエラーはありません
トレードオフ この仕事やるのと休日出勤どっちがいい?
動きます 完成度10%
一部のエラー処理がまだ 完成度20%
誰かの独自フレームワーク お前はしぬ
会社独自フレームワーク みんなしぬ

2015-07-22

http://anond.hatelabo.jp/20150722194814

主観は人によって違うのでやむをえないが俺の立場は以下のとおり。

表の論点 安保法制合憲かどうか

私:憲法学者が言っているし、違憲だろう

君:今までの解釈の延長線上にあるから問題ない

俺:今までの解釈の延長線上にあるから問題ない

裏の論点 どのくらい現政権フリーハンドを認めるか

私:憲法範囲内で枠にはめたい

君:今は緊急事態からできるだけ憲法拡大解釈すべき。改憲大変すぎ。

俺:今までの解釈の延長線上にあるから、少なくとも新たな問題はない。(9条改憲するときにかかる時間コスト言及したのは、君の主張のデメリット矛盾をつくためにすぎない。俺は先の解釈変更や今般の安保法制のための程度なら9条改正不要との考え)

少し付け加える。

今までの解釈憲法範囲内だというなら今般の法制もすでに枠にはまっている

時の政権特に9条に関する限り、事実上ほぼ無制限解釈自由があることになると見ることが可能なのは事実だ。

しかしそれは、現在制度自体がもつ欠陥(統治行為論により9条に関する限り行政府の一部門合憲性を事実上最終的に判断する制度)に起因している。制度の欠陥を安部首相がついたとみてもよい。

これが9条だけの話ならばまだしも、他の条文にまで援用されると確かに恐るべきことになる。

論点の背景にある価値観の相違

私:民主主義大事。そのためには狭義の「国益」を多少犠牲にしてもやむを得ない

君:民主主義大事だが、国民幸福の前にはある程度の手続きショートカットは許される

俺:デモクラシーイデオロギーではなくプラクティスである

補足)

原語がデモラティズムではないことにそれは現れている。したがってデモクラシーによって守られるべき価値デモクラシーのものによって毀損されるのはゆるされず、その価値とは「国民幸福である

なお、侵略が許されないのは、それによって得られたなにかをわれわれ日本国民はもはや「幸福」とは呼ばないからである

また、近代デモクラシー以前から国家存在している。デモクラシー採用しない国民国家はありえるが、国民国家の基盤がないところに近代デモクラシー不可能さら国民国家国家の一種に過ぎず、国家領域人民暴力によってなる。(つまりよりもっとも野蛮な国家すら、領土人民防衛はその責務である。ましてや現代日本においてをや)

より下部にあるより基礎的な層への脅威はそのままわれわれのデモクラシーへのより根源的な攻撃でもある。これへの防御を表層の制度字義解釈に拘泥して阻害したり、それをもってデモクラシー破壊と叫ぶのは本末転倒。むしろ表層にある制度の欠陥が露呈したとみて、制度改善こころみるべきである

さら政治は結果である

制度改善が著しく困難な時には、より基礎的な価値防衛するために統治機構はさまざまな方便を考え出す。

今回の解釈変更も、そもそも安保自衛隊を黙認するための統治行為論もそれだ。

価値観を作る根っこにある、もっとも恐れている事態(たぶんこの部分のリスク計算が一番違う)

私:国内制度崩壊

君:外国侵略

これについては、まあ、君にはそう見えるかもしれんという感じか。

俺にとって外国侵略が君が考えるよりは重大な危機と考える理由の一部は「論点の背景にある価値観の相違」の補足に述べたつもりである。多少分かりにくいかも知れないが、筋道はおえるのではと思う。

ところで君は先に大戦惨禍を縷縷述べ、その原因を国家暴走にもとめた。

そして、それへの反省あるいは対策として、立憲主義の厳格なる遵守を要求していたように見える。わたしの考えもまた私の主観では立憲主義を厳格に遵守するものであるがそれはともかくとして以下の点を指摘する。

天皇親政により立憲政治を絶命させようとした二・二六事件立憲主義を逸脱した昭和天皇勅命によって頓挫させられた。先の大戦はやはり立憲主義を逸脱した昭和天皇聖断によって収拾された。

デモクラシーが前提とする立憲主義手続きを墨守することによる不利益デモクラシーコストとして甘んじて受けるべきだというなら、昭和天皇は指をくわえて見ているべきだったということになる。

もし本当にそう歴史が推移したならば、前者についてはより早く大戦突入する結果を招いたことであろうし、後者については惨禍がどれほど拡大したかはまったく俺の想像を越える。

こうした歴史をどう考えているのか。

しかし、これはもはやあまり脱線が甚だしい。縁があれば別の機会に議論することにしよう。

2015-05-23

健康長生きするためのベストプラクティスはあるはず

健康長生きするためのベストプラクティスはあるはずなんだけど、

それが確立されていないような印象をうける



いや、ガンにならないようにとか、痴呆症にならないようにとか、生活習慣病にならないようにとか、

いろいろ健康的な生活を送るための情報はあるんだけど、まとまってないというか、

あんまりにも、特定病気ごとの話になっていてその病気に興味のない人に縁が無い



そうじゃなくて、病気心配をしなくていい生き方を知りたいし、健康を気にしていない人にも広まってほしい

2015-04-15

http://anond.hatelabo.jp/20150415090043

なんかレイヤが混ざってる気がするな。

確かに最適化っていうのはプラットフォーム依存するんで、ハードインフラが変化すれば不要になるものも多いよ。でもさ、ハード進歩を1年待つより今出すことに意味があるってことはよくあるわけさ。

このゲームエンジン重いけど最適化しても次世代機ならどうせ無駄になるんだから最適化やめましょう、ゲームタイトル次世代機出た後にリリースしましょう、とか言ってたらいつまでたってもワクワクするものは出てこないよ。

で、アプリプラクティスが下層に影響されるのはそのとおりなんだけど、例えばかつて中央CPUで処理してたのが分散してローカルで処理しましょうってなってそれがまたサーバアプリ乗っけようってなってそこからさらにいやクライアントにも振ろうってなって、でもこれって決して単に行ったり来たりしてるだけじゃなくて、スパイラルを描いて少しづつ昇ってるんじゃないかな。環境が一巡したときに、昔の技術のうち汎用性の高いものけが蒸留されてさ。

2015-02-05

http://anond.hatelabo.jp/20150204233403

脆弱性につながるバグというものがあって、それは入力チェック(バリデーション)で防げることもあるということだろ。

逆に言えば入力チェック(バリデーション)してないことで作りこんでしまバグの中には脆弱性を生むものも多々ある、と。

言っていることは何もおかしくない。言葉定義がみんなちょっとずつズレてるから間違っているように見えるだけだ。

アプリケーションが正しく動くための処理だ。それができていないのはただのバグだ。

私はそこまで単純に言い切れない。

文字だと思っていた値が謎のバイナリだったとしてもアプリケーションほとんどの場合正しく動くとしたら。

高々100文字程度だと思っていた文字列が100KBくらいあったとしてもアプリケーションほとんどの場合正しく動くとしたら。

アプリケーションの外部仕様を「ゆるく」設計してしまうこともあるんじゃないのか。

そして、その仕様に沿って入力チェック(バリデーション)を「ゆるく」実装し、

その仕様に沿った「ゆるい」テストをするのではないか。

実際、アプリケーションにはバグがないのだから、これで問題ないことになるだろう。

しかし、入力チェック(バリデーション)がゆるいと、周辺ライブラリの潜在的なバグを踏む可能性がそれなりに高いから

安全のためにもアプリケーションの外部仕様は「問題ない範囲で厳密に」設計しておけ、というプラクティスは何か間違っていだろうか。

2014-09-01

SIer人海戦術なのは仕方の無いこと

SIerには、コンピュータの仕組みをよく知らない奴が毎年大量に入ってきて

しかも向いてないとか体調崩したとかい理由新人に限らず中堅どころもどんどん離職していく。



そんな素人軍団で大規模なシステム作成しなければならないとなったとき

ウオーターフォールを採用し大量の仕様書やらExcelスクショを作るという

誰がやってもある程度ぶれのない仕組み化をするのが現時点でのベストプラクティスであると思う。



反論歓迎です。

2014-07-02

外人に道を聞かれた時のベストプラクティス確立した

過去は教えた後にちゃんといけたかなーと不安になってたけど、この方法はすげー安心

道を聞かれる

場所を確認する

※注目※

グーグルマップを持ってるか確認する「Do you have a google map?」

相手のスマホを借りて、場所を打ち込んで検索する

Here!」

ッて感じ。

Google先生、最高。

グーグルマップ持ってなかったら詰む。

これ、ほぼ迷わない。と思う。

2014-04-23

アプリ紹介記事を駆逐したいです……

何にイラついてるかって、「人気エントリに入ってきてウザい」「なんだよ焼き直しじゃねえか」「はてブやたらついてる」「PV稼ぎかよクソ」「英語勉強記事と同類だわ」「入れるべきって、あんたの仕事環境趣味嗜好を根拠にすんな」「また全部MacVimじゃねえの」とかそういうことを思うわけ。

とは言え自分もそういう記事を参考にトレンドを知ったりしてお世話になってきた部分もあるんだけど、じゃあ自分も同じように紹介して還元したいかっていうと、そうじゃない。だけど需要はあるみたいだ。みんな、良いアプリを知りたいんじゃなくて、自分の作業をもっと楽に早くできないか考えてるんじゃないかな。

アプリはあくまで道具。どんな目的を達成するために、どう組み合わせて、どういう手順でそれを使うのか。それを導入すると、どういう人がどう嬉しいのか。それをはっきりさせてほしい。それが理解できないままインストールするなんてことはしたくない。

から、業種や職種、OS、作業目的を明示したレシピを公開して共有するサービスがあれば素敵じゃないか。例えば、

といった感じでぱっと自分の思いついたもの適当に上げてみました。

で、投稿されるレシピに含まれるアプリ統計を取ってトレンドを探ったり、時代の移り変わりに応じてレシピバージョンアップしたり。黒い画面に抵抗がある人はそれが含まれるレシピを省いて検索。同じ作業目的でも効率に差が出るレシピには知識要求レベルも割り当てることでステップアップ形式にするとか。

これらを充実させていけば、目的に特化したレイアウト規格化・整理した状態で横に並べて比較参照でき、それに慣れた人々はエゴに満ちた中途半端ブログ記事のクソデザイン邪魔サイドバー、冒頭のよくわからない挨拶、わざわざ自サイトでそれをやることにイラついて糾弾が加速し、次第にアプリ紹介記事は消えていくことになるでしょう。そして結局何を目指しているかというと、

業務フローオープン化して、みんなでベストプラクティスを構築しよう

ということなのです。会社としての強みとしてそういったノウハウを抱え込むのもよいですが、なんかもっとレイヤーで競いあったほうがいいんじゃないのとか思うわけです。業務フローオープン化したらプレイヤースキルが汎化されて、より人材流動性も高まって、もっと人間しかできないようなことで悩めるようになるんじゃないでしょうか。

また似たようなクソ記事を発見して機運が高まってきたら、少しずつ作り初めてみようかと思います

クックパッド料理ならテックパッドとか?

2014-04-07

http://anond.hatelabo.jp/20140407200527

初心者向けの入門本読むぐらいなら、とにかく書く、のほうがいいとは思う。

ただ、プロでやるなら本をじっくり読むのも必要

入門本とかじゃなく、「プログラミング作法」「コードコンプリート

みたいなコーディングベストプラクティスの載った本を1冊は読む必要があると思う。

2014-02-28

去年はじめから現在まで

2013年1月か2月

プログラミング経験、ほぼ皆無。

HTMLCSS, JavaScriptちょっとだけ分かる

dotinstallとか見てブラウザタイマー作ってわーいって喜んでるくらいのスキル感。



プログラミング勉強したい

勉強したいけどスクールとかはお金かかるから嫌だ

→本を買ってやるのは安上がりだけど途中で挫折しそう

→じゃあお金稼ぎながら学んだらいいんじゃ

プログラマバイト探そう



求人サイトで見つけて応募してみる

経験でも大丈夫らしい

バイト始めることになった



バイト始まる

はじめは研修アルゴリズムPHPについて

課題を出されて、できたら業務に入れる

フレームワーク使って指定されたwebサービスをつくる

基本自分の力でつくる。放置される

誰も教えてくれない

今思うと初心者やらせるのはなかなかハード

ググってググってググりまくる

他のできる子はさらさらっと1週間くらいで終える

ひーひー言いながら2~3週間でなんとか終えた

この期間、ほとんどプログラミング以外のことしてない

なんとかなった



3月4月

PHPドキュメントを読む習慣がつく

ググってコードコピペして動かしてみる、という段階

動くと楽しい 分かると楽しい

このときくらいにパーフェクトPHPを読んだ。FWは、つくれる!

FWがなんたるかをやっと理解し始める

あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね

分かった気になる←分かってない

HTTPリクエストについて気にしだした

GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない

フレームワークはいくつも種類があることを知る

このころ、Sinatraという言葉を小耳に挟む。支那虎?



5月6月

FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービス受託をやる

まあ良い経験になった

フレームワークいくつかやって、web開発のいろんな概念tipsがたくさん頭に入ってきて、

あーあれかーくらいには思えるようになった

DBCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインコード生成,認証周りのプラクティス ...



7月くらい

さて、バイトが本格的?になってくる

一人で開発 責任おもい

機能追加のタスク

ごく一般的機能

でもなんか躓いた。

書いたコードに自信が持てない

これでいいのか不安になって手が進まない

やっぱり自分で考えて経験したことのないことはなかなか難しい

DBのテーブル構成を理解するにも骨が折れた 命名規則大事

セキュリティで手直しはたくさんもらった

フレームワークにはDB操作ライブラリがちゃんとついてるのにそれ見ずに自分SQL組み立てて案の定エスケープしてないし、とか

必要ないところでCSRF対策してるし、とか

でも、なんとか完成させた

プッシュして、マージされて、できちんと本番環境で動いてる。やったね。



8月9月

Rubyを知った

PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。

ちょっとだけ触ってみた。使いやす

Railsも知った

それからは空いている時間の大半をRubyRailsにつぎ込んだ

まずはRailsTutorialをやってみた

テスト周りでつまづいたけどなんとか終わらせた

dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ

はじめはRuby理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた

はじめてのRuby・はじめてのプログラミング・たのしRubyプログラミング言語Ruby... 入門系の本を乱読した

PHPでさんざん苦労していたからか、Rubyオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた

Rubyドキュメントの読み方を覚えた

その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra支那虎じゃなかった)やらについて学んだり、

メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatz言葉痺れたなー

バイトのほうも何とかこなせるようになってきた 成長すげー



9月10月11月

Vagrantをかじる

インフラ・ミドルネットワーク周りに興味がでてくる

AWSでいろいろ遊ぶ

メタプログラミングRubyは断続的に2~3回ほど読み返す

Rubyってほんと使ってて楽しい

webスクレイピングとか検索APIとか使ってムフフ画像をアハーンしたりして遊んでた



11月12月

Rubyと名のつく書籍を読みあさる

Ruby言語をつくろうだの、スクリプティングを極めようだの、JavaRubyがどうだの。

メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。

借りられる本は借りて済ませた。全部買ってると破産する

他にもRubyとつかない本もいろいろ。

達人プログラマーは途中で挫折した。そのうちもう一度読む

プログラマが知りたい97の何とか。いい本

Ruby関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる

OOPと全く違う。



2014年1月2月

就活はじめるよー

まあ、エンジニア枠で探すことにする

エントリーめんどくさい

ので、1社受けて落ちたら次の会社エントリーするという作戦にした

無計画玉砕作戦

はいえ、なんとかなると思ってやってく

気を揉む期間

いろいろな会社採用ページ眺めていると気になること

入ってやる仕事の内容が分からない

やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない

せめてよく使ってる言語くらいはのっけておいて欲しい。



気になる会社はいろいろ調べる

で、1社選んで応募して、選考が始まった

面接、失敗したなと思ったところもあったが

嘘つかない

知らないことを知ってるように話さな

は通せたので良かったと思う。

で、進んでいって最終面接。これもなんかよく分からないうちに終わってた

相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる

うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。

から気になってた会社ではあった。勝手リスペクトしてた会社

自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる

いろいろと運が良かった。嬉しい

他の会社はどうしようかな。

受けてみたい気もするけれど、エントリーがめんどくさい

続けるかどうかは未定だけど、ひとまず休憩することにする



今は、関数型言語についての本買って読んでる。関数型、Rubyに劣らず楽しい

ログイン ユーザー登録
ようこそ ゲスト さん