サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
neos21.hatenablog.jp
人に質問する時に、 「○○が動かないんですけど……」(← けど、何?) 「○○を設定したら△△ってエラーが…出て……これって……○○の……バージョンが……」(← 何が質問したいの?) っていう、尻すぼみになる質問の仕方をする人によく遭遇する。途中から消えそうな声で喋るから「文末までハッキリ堂々と喋りなさい」といつも言っている。 この質問の仕方は複数の理由から忌むべき聞き方なので、即刻止めよう。 「○○が動かなくなってしまいました。どうすれば良いか皆目検討も付かないので教えていただけませんか?」 「○○を設定したら△△というエラーが出ました。○○のバージョンが古いせいかと推測しているのですが、これに関する文献やノウハウはご存知ないでしょうか?」 このように、「助けて欲しいです」「このように手を差し伸べてほしいです」とハッキリ言おう。 前者が悪い質問の仕方である理由、後者のように聞くと良くなる
飲み会撲滅委員会会長 (自称) の Neo です。 飲み会のない会社を求めて、勢いで以下のような求職記事を作った。 gist.github.com 現職は、公私混同でただ仲良くするだけの「コミュニケーション」と、適切な報連相を行えるスキルとしての「ビジネスコミュニケーション」を履き違えている。まぁ大体どこの会社にもこういう風潮はあるけど、酒が飲めない人間にとっては飲み会の2・3時間も苦痛で仕方ないので、飲み会がない会社を探したくなった。一緒にメシ食おうとか酒飲んで交流を深めようとか寝ボケたことほざかない企業って、本当にないんだろうか。調査も兼ねて。 自分のスキルシートみたいなのは、GitHub の About リポジトリを作っていたりもするので、あまり迷うことはないが、働き方とかビジネスに対する思いのなさとかって、上手く言語化しづらいところもあった。 ビジネスコミュニケーションは超重要だと
言いたいことが確実に伝わる 説明力 (アスカビジネス) 作者: 五十嵐健出版社/メーカー: 明日香出版社発売日: 2014/03/12メディア: 単行本(ソフトカバー)この商品を含むブログを見る どんなときでもバッチリ伝わる!説明力があがるコツ 作者: 佐々木恵出版社/メーカー: ごきげんビジネス出版発売日: 2017/05/31メディア: Kindle版この商品を含むブログを見る 「口で説明した方が早い」「口頭の方が伝わる」と思っているのは、発信者だけだ。受信する側は、話された順に情報を受信するので、発信者が話をする時系列に支配される。これは受信者の理解を妨げる大きな要因になる。 話した側は、話しながら頭の中で情報を整理できるので、話す前よりも理解度が増した気になってなかなか気付きにくい。 しかし、話される側からすると、自分が理解したい順に情報が得られず、「ところで最初に言っていた○○の
エクスプローラであるフォルダ内から一つのファイルを探す時 あるソースファイルの中から特定のメソッドの宣言を探す時 表資料の中から今話題にしている書籍名を探す時 このような、「一覧の中から特定の文言の行を探す」ことを、ココでは便宜的に「目 grep」と呼ぼうと思う。 で、最近特に思うのが、「みんな目 grep トロすぎでしょ」という不満。 ファイル一覧なんかであれば、ファイルは大抵名前順でソート表示しているだろうから、A to Z でアイウエオ順、という並びは分かっているはずなのに、「MT_1012.xlsx」を探し出せずに「SE_8091.xlsx」のあたりまでスクロールしていたりする。S まで来てたら M はとっくに過ぎてるだろ!!バカか!! ソースを調べる時も、「クラス」→「フィールド変数」→「メソッド」といったインデントは大枠としてあるワケだから、メソッド定義がどの辺にあるか探すのに
「言われていたものを作りました。はいレビューしてください」というレビュー依頼の出し方をしていないだろうか?それはレビューイにとっても、レビューアにとっても、多くの無駄が生じるので、止めよう。 色々と思うことがあり、考えがまとまらなかったので、箇条書きで書き出すだけにする。 何が悪いのか? レビューアがレビューしていて、成果物のある部分について「どうしてそのように書いたのか」と疑問に思った時、理由や経緯が分からないので、レビューアが調べなくてはいけない。 レビューアが調べて「多分こういう理由でこう書いたんだろうな」と推測した内容は、レビューイがそのように書いた経緯とは異なるかもしれない。そうすると、レビューイの意図が正しいかどうかを検証できておらず、思わぬところに悪影響を与えていることに気が付かないかもしれない。 レビューアが調べ直しても分からなかった場合、レビューイに「何でこういう風に書い
Apache Cordova というフレームワークがある。別名 PhoneGap と呼ばれるこのフレームワークを使えば、HTML・CSS・JavaScript で構築したアプリを、iOS・Android 向けのネイティブアプリのようにビルドして配信できる。クロスプラットフォームに対応した、いわゆる「ハイブリッドアプリ」を構築するためのフレームワークだ。似たようなフレームワークに Electron や React Native などが存在するが、その構造はそれぞれで異なる。 ここしばらく、この Cordova というフレームワークを使う案件にいたので色々いじっていたのだが、とうとうその限界というか、現状どうしても拭えない難点を認めざるを得ないな、と思い、今日の記事を書くことにした。 Cordova は OS の差異を埋める緩衝層 Cordova の仕組みは、HTML・CSS・JS でコーディ
みんなが知っておくべき運用設計のノウハウ 作者: JBSテクノロジー株式会社発売日: 2017/10/30メディア: Kindle版この商品を含むブログを見る ITシステムの罠31 システム導入・運用で絶対に失敗しないための本 作者: 安茂義洋,栗谷仁出版社/メーカー: 実業之日本社発売日: 2015/04/30メディア: 単行本(ソフトカバー)この商品を含むブログを見る 個人の開発環境と違って、間違えてしまった時に甚大な被害を引き起こしてしまうのが本番環境。誰もがミスをしたくてするワケではないが、様々な要因の積み重ねで、問題を起こしやすいチーム、起こしにくいチームの差が生まれる。 今回は、本番作業でのミスをなくしていくための対策を色々と考えたいと思う。 「ミスしないようにする方法」と「ミスしても大丈夫なようにしておく方法」 作業環境が区別できるようにしておく 作業者の心構え ミスした時に
発端 2015年の暑い夏の日。僕のデスクの電話が鳴った。僕が客先常駐して保守している社内システム「マハーカーラ」の主担当からだった。 「今マハーカーラに商品データを入れてたんだけどね?『次へ』ボタンを押したらログイン画面に戻されて、入力中のデータが消えちゃったの!一括登録しようとして30件分入力してたのよ?データ復元して欲しいんだけど!面倒臭いのよこの入力!商品名入れてから次の画面に行ってカテゴリ選んで、確認画面で確定ボタン押さないと確定できないんだから!」 主担当は、これまでの入力作業が水の泡になるのではないかという焦りからか、電話口でまくしたてた。残念ながら、「マハーカーラ」は優秀な Web システムではない。フォームに入力している最中の情報などキャッシュされているはずないだろう。僕は残酷な現実を伝えなくてはならなかった。 「申し訳ありません。確定前のデータは DB には保存されており
僕は普段から、日本語と英語の間に半角スペースを入れて記述している。英単語はスペースで1単語を区切るワケだから、日本語との境界にスペースが存在していないのは不自然に感じるのだ。 これに関して、オレオレルールがいくつかある。 基本ルールとしては、日本語と英語の間に半角スペースを入れる。 日本語 English という風に、半角 Space を開けて記述する。 日本語の句読点やカギカッコに隣接する英単語とはスペースを開けない。 こういうカギカッコにくっついている時は「Space を開けない」。それに、Period などに隣接する場合もスペースを Not Open。 数字が絡む場合は、適当にスペースを開けたり開けなかったりする。 2017年4月10日、という場合はスペースを開けないが、例えば時刻を表す 12:15 みたいな記述だとスペースを開けたりする。 境界が自分でも曖昧だが、数字と日本語で1つ
Terasoluna という NTT データが提供するフレームワークがある。乱暴に言うと Spring と MyBatis のラッパーだ。 とある現場でこれを使って、ゲロ吐くほど使いづらかったので愚痴る。なお、現場ルールも相まって相当に使いづらかったので、Terasoluna 単体の仕様ではない話もちょっとする。 このフレームワークは元々規則で縛り上げる設計で、「設計書が書けたなら実装は誰がやっても同じようになるはずだ、いや、同じになるようにするのだ!」という設計思想が見える。似たようなクラスをイベント (ボタンの押下) ごとに作らせ、不必要なまでにしつこくインターフェースを継承させる。 これまで Struts1 系を仕事でやらされてきたのから比べると、Struts は自由度が高過ぎて、データの受け渡しを如何様にも書けてしまう。Terasoluna はそういった「一見すると結果は同じだけど
参考:最近のビルドツールって何なの? - 檜山正幸のキマイラ飼育記 参考:gulp問題ひきずり:ウォッチがまたおバカ過ぎる - 檜山正幸のキマイラ飼育記 参考:[意訳]私がGulpとGruntを手放した理由 - Qiita 参考:フロントエンド開発の3ステップ(npmことはじめ) - Qiita 参考:npm で依存もタスクも一元化する - Qiita 参考:uu59のメモ | npm runだけだと厳しくなってきたのでshelljsを使うことにした それまで Qiita なんかを見るだけで過ごしていた自分が、今年 Gulp の勉強を始めようという時、Grunt ってのはどうもオワコンになりつつあるらしいな、ということで Gulp を選んだのだけど、最近は「npm run で大体やれるし package.json に書いておけばいいじゃん」な流れがあるっぽい。 確かに、Gulp や Gru
参考:ヨーダ記法 - Wikipedia Java において String#equals() で比較をする時に、「対象の変数が null の場合に起こる NullPointerException を回避するために定数を先に書け」と言われて、それまでプログラミングしたことなかった新人の俺でさえ嫌悪感が凄くて、結局「つか null チェックしないのが悪いんじゃん、そんなに null が嫌なら StringUtils#equals() でも使え」と言って現場のコーディングルールを変えたことがある。 ヨーダ記法の違和感は、自然な英語として読んだ時に主述が逆転することにある。だが、英語ができない人間はそもそもソースコードを「英文」とは捉えていないので、当然変数名もメソッド名もグチャグチャ、テキトーな英語使って平気で regist() メソッドとか作っちゃう。彼らは自ら書くコードさえ、ただの召喚魔法み
コードを日本語訳したような設計書。CREATE TABLE 文を表形式に変換した定義書。これらは「Excel 方眼紙」と呼ばれる日本の SE 業界を象徴する伝統的な手法で記述されており、ロクにメンテナンスされることなく引き継がれ、保守担当者を困惑させる。 今回はこうした設計書がなぜ存在し、どうしたらこんな醜いものをなくせるか、考えたい。 対象とするのは、ブラウザからアクセスできる、Web アプリケーションとして動作する社内のアレコレを管理するようなシステムを作る場合。組み込み系などは経験ないので、ソフトウェア開発における話、それもインターネットに繋がっていない環境で仕事をさせられているような時代遅れの SIer に限定させていただきたい。 漠然と思った順に書き殴っていくので、乱文です。 自分の基本主張 コードファースト。ソフトウェアは実際に動いているコードが主たる成果物であり納品物。設計書
このページを最初にブックマークしてみませんか?
『neos21.hatenablog.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く