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

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

2017-07-26

https://anond.hatelabo.jp/20170726121912

「作者が10時間くらいかけて考えたことを1秒で考えたことにする」

「作者が10時間くらいかけて調べたことを元から知っていたことにする」

「周囲の頭が良い人たちの行動をそのまま書く」

歴史上の偉人エピソードアレンジして使う」

このあたりがベストプラクティスっていうか普通にどの作家もやってる。

「作者より頭の良いキャラは書けない」という命題自体が偽。

2017-07-24

https://anond.hatelabo.jp/20170724080818

この期に及んで、弁護士警察指南した「ベストプラクティス」にすがってマニュアル通りの対応をしてしまってるのが残念でならない

2017-07-10

Webアプリを作るときにどの言語/WAFで書くべきか

使ったことあるモノもないモノもごちゃまぜにして経験雰囲気で書いてる。

PHP

Laravelは結構好き。DSL過ぎず、それなりにフルスタック生産性もいい。

何よりLaravel本体ソースコードが読みやすいのがいい。

まともな日本語情報が少ないのは弱点だけど、気になったところは本体コードを読めばすぐに分かる。

最大の欠点PHPってことだ。他のLL言語に比べてPHP自体生産性は低い。セキュリティ面の不安も大きい。それに安心して後を任せられるようなPHPerは一握りしかいない。

Perl

Mojolicious結構好き。これもDSL過ぎず分かりやすい。CPAN豊富ライブラリ群もある。

Perlは可読性が悪いなんて言うけど、ちゃんとしたライブラリ普通に読みやすいよ。

最大の欠点Perlってことだ。長期的に開発者を集めることを考えたら茨の道だろ?

Python

今でこそ機械学習Pythonが人気になっているけど、Web系はまだまだマイナーだ。

Djangoプロジェクト/アプリケーションという構成単位の考え方が好きじゃない。理論的な利点は分かるけど、現実問題それが必要になるケースが浮かばん。

Django以外でフルスタックのWAFが出てくればいいんだけど。Tornadoはフルスタックじゃないのでちょっと違う。

Python3で安心して開発できるならアリだと思うけど今はどうなの?使いたいライブラリが3系に対応していないとかで躓きたくないよ。

あと単純に速度が遅いよね。いや書き方を気をつければマシにはなるんだけど、書き方を気をつけなければいけない時点でつらい。

Ruby

Railsは便利だ。周辺ライブラリの充実度もすごい。情報玉石混交だけどまともな情報もたくさんある。

ただあまりにもDSL過ぎる。Railsプログラミングではなく、一つの巨大なDSLだ。

Railsプログラマの何割が、少しでもいいかRails本体ソースコードを読んだことがあるのか。めっちゃ読みにくいんだけど。Rubyは可読性が高いなんて嘘だろう。Perlと一緒でちゃんとしたコードは読みやすいけどそれはプログラマ依存する話で、言語自体に可読性の高さはない。言語思想の通り書くのは楽しいよ。でも読むのがつらい。

Rails自体DSLみたいなもんなのに、RSpecやらRakeやら周辺ツールDSL意識高すぎる。

問題があった時にググらずにコード読んで解決できるRailsエンジニアはどれだけいるのか。情報量が多いからググれば解決すると答えるやつは、底辺PHPerと大差ないからな。

あとバージョンアップ追従するのが面倒過ぎる。でも放置したら負債になるし。意識高くRailsで開発したやつの大半はバージョンアップやらの保守に入る頃にはもうそプロジェクトはいないんだろ?だからそのつらさを知らないんだろ?

散々罵ったけど、このDSLを覚えれば生産性が高いのは事実だ。だから結局ついていく確率が高い。モテ男なんだよ結局こいつは。

Java

SIerさんに敬礼

Scala

Playが王道だけど最新バージョンになるほど情報が少ない。このあたりがRailsと違う。公式(英語)とか本体コードを読める人じゃないとつらい。

そもそもJava、というかJVM周りの知識がないと本番運用はつらいだろう。LL言語運用経験しかない人は特につらい。LL言語でいうhot deployみたいなことがしたい時のやりかた分かってる?

コンパイルの遅さに耐えて開発し、運用時のGC問題を乗り越え、黒魔術を味方につけてライブラリコードリーディングが出来るならいいんじゃないか

動作は早いし、言語のものは強力だ。

Scalaを好むプログラマ関数型やらDDDやら意識高い人が多い。別にScala自体にそれらは必須ではないけど、そこら辺を意識しないならJava8でいいんじゃないかとも思う。

Node.js

非同期処理で開発することの難しさに耐えられるの?

ベストプラクティスがなく、移り変わり激しいJS界隈に流されてオレオレで書いたコード保守する自信があるならいいんじゃない。俺はない。

Go

API単体ならともかく、画面も担う普通Webアプリを書くような言語じゃない。少なくとも今は。

正確に言うと書けないことはないけど、Webアプリに関する周辺ライブラリの不足を乗り越えてまで書くメリットほとんどない。

ClojureとかElixirとか

運用実績ノウハウが少ない中で、自分で乗り越えていく気概があればいいんじゃない

結論

完璧選択などない。

2017-06-06

Rubyから解放

最近Python にどっぷり浸かるようになって、「Ruby 教」とも呼べる宗教的な縛りから解放されるようになってきた。それにつれて、いままで Ruby コミュニティで当たり前とされてきたいくつかのプラクティスに対して批判的な気持ちが育ちつつある。

いままで一部の人たちが Ruby 界隈を忌み嫌っているのを見てきたが、その理由がわからなかった。でも、Ruby一種新興宗教のようなものだ、と考えればその理由理解できる気がする。

プログラミング思想というのは、絶対の正解がないために、結局、それを信じる人たちが集うという「信仰」の形を取るしかない。より主張の強いグループ宗教的な形を帯び始めるのは少しも不思議ではないだろう。

なんかマジ、Ruby ダルくなってきたわ…。

P.S.

特にキモいのは、RSpec

Ruby変態 DSL の極みみたいなもの

Python のほうがスッキリしていてずっといいわ…。

P.S.2

Rubyな人たちは二言目には「テスト」とかいうけど、自動テストがすべてを救ってはくれないよね。

テストコードメンテ自体、莫大なコストがかかるし。

私は、テスト必要最小限にして、メリハリを効かせて書くべきじゃないかと思う。

基本的には、リグレッション対策で十分な気がするけどね。

2017-05-31

日本語でいえばいいじゃん

デフォルト⇒初期値

〇〇マター⇒〇〇の責任 / 〇〇の仕事

リスケ⇒日時変更

フィックス⇒決定

コミット約束

ビジョン展望 / 見通し

マスト絶対

シミュレーション⇒試算

アセット資産

アナウンス⇒周知する / 知らせる

エスカレーション⇒報告

プライオリティ優先順位

ペンディング見送り / 保留

シェア⇒共有

バイス修正

ブラッシュアップ⇒改良

アジェンダ⇒議題 / 行動計画

コンセンサス同意 / 合意

グリー同意

スキーム⇒枠組み / 仕組み

ソリューション解決方法 / 改善案

バイアス⇒偏り

オーソライズ理解を得る / 通す

エビデンス証拠

タスク課題 / 仕事

ドラスティック⇒劇的に

ナレッジ知識

バッファ⇒余裕 / のびしろ

スペック機能 / 性能

ミーティング会議 / 話し合い

フロー⇒流れ

ストック在庫 / 貯蔵

スタック⇒退避 / 止まる

ファクト事実 / 事象

ドラフト草案 / たたき

ボトルネック⇒原因

ベストプラクティス⇒最適解 / 最良な方法

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の私の言葉意味

追記歓迎

言葉意味
議事録気が変わる前の意見
非機能要件実装するかは気分次第
確認しておきます今日は帰ります
オブジェクト指向オ○ニー
偉い人の意見パルプンテ
ちょっとした仕様変更ザキ
客先担当者の急な交代ザラキ
要件定義から見直しザラキーマ
確定した仕様幻想
WBSSはサグラダファミリア
キーマン鬱病になりにくいことがわかってる人
ベストプラクティスモジュール化されてません
増員導入教育で作業が止まる
それは新しい方法ですね問題がおきたらお前が対応しろ
操作手順書唯一多少参考になる設計ドキュメント
備考最も重要考慮事項
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で処理してたのが分散してローカルで処理しましょうってなってそれがまたサーバアプリ乗っけようってなってそこからさらにいやクライアントにも振ろうってなって、でもこれって決して単に行ったり来たりしてるだけじゃなくて、スパイラルを描いて少しづつ昇ってるんじゃないかな。環境が一巡したときに、昔の技術のうち汎用性の高いものけが蒸留されてさ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん