サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
taichiw.hatenablog.com
プレゼン資料のアップロード。 もともとSlide Shareを使っていたため、ちょっとイライラする事があったり、「イケてるエンジニアの人のSpeaker Deck率高いなぁ…」と思いつつもSlide Shareを使い続けていたのですが、 何やら技術的な理由*1によって再アップロード機能を廃止したとのこと。 www.linkedin.com 私も技術屋の端くれなんで、 You will still be able delete your older SlideShare files and upload new presentations. って言いたくなる気持ち、わかります。「更新」って意外とメンドウなんだよね。単なる新規登録に比べて。 …とはいえ、これは利用者としては受け入れられねーわ。 自分が発表した後に、ブログからリンクしてもらったり、埋め込んでもらったものを全く変えられないというの
こちらの本を読んででのレポートです。現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法【電子書籍】[ 増田亨 ] 価格:3175円 (2017/11/4時点) 複雑な業務ロジックは「適切な境界」で分離されていれば理解しやすくなる! …が最近の自分の持論なのですが、じゃあ「適切な境界」って何よ? …と言われると、うまく言語化説明できない。 そんな私にたくさんヒントを与えてくれた本でした。 なかなか消化しきれていないところもあるのですが、腹落ちさせるためにもブログに落としてみます。 このブログに書いたことをまとめると・・・ 修正が大変なのはロジックが分散しているから データとロジックをひとつのクラスにまとめるとロジックが分散しない! じゃあWeb APIでサービス間連携するときも、データを持つほうにロジックを寄せるべき… と思ったら、そうでもない? この本のすごい
楽天テクノロジーカンファレンスで聞いた、漆原茂さんの『一生、エンジニアで食っていこう』というセッションのレポートです。 私的に刺さった話 0x30歳ころ 何歳でも技術で仕事したい!…と思った。 そのためには、自分自身の「進化」が大きな課題だった。 「昔はこれこれ項で苦労したんだぞ」的な「技術おじさん」にはなりたくなかった。 若返りながら進化できる唯一の生物を探したら…… 一つだけ見つけた。ドラキュラ!(笑) 「若者のエキスを吸う」ために ・若いコミュニティに飛び込む ・若い人をメンターにつける 最先端に居続ける 外を知るために、イケてる人に会いに行く。 SNSで探してメッセージを送ったり、メールを送って直接話したり。 セミナーは話を聞くためではなく、偉い人と仲良くなるために行く。 会いに行くコツ 質問しに行かない。言いたいことを言いに行く。 ビジネスネタとLTを準備しよう! イケてる人と繋
今日はとても素敵な一日になりました。 私を含めたチームメンバー9人が、一つの技術的な話題に対して30分話し合う会を開けた日。 何より嬉しかったのは、この会そのものが、メンバー間でのやり取りからほぼ自然に出てきたことなんです。 回想:本当に「スモール」だった時期 私の今のチームは総勢9名のチームなのですが、大まかに分けても4種類くらいののサービス(検索から予約、管理画面も。)を担当している、プロダクト的にはかなりマッチョなチームです。 これらのサービスはどれも「似ている」のですが、歴史的にバラバラに作られてきたため、アーキテクチャやフレームワーク、コードの思想は全部バラバラです。 以前は、このバラバラなプロダクトを、チーム内でもバラバラに担当がついていて、2~3人の少人数チームが3つ、という状態でした。 「似ている」ものをバラバラに作っているので、同じようなものをお互い作っていたり、同じよう
CROSS2015というイベントに参加してきました! パネルディスカッションに参加した! 今回の主目的は、パネルディスカッションへのパネラーとしての参加。 旅行ECサイト各社に聞く成長の秘訣とこれから と題された、異色のパネルディスカッションに参加してきました。 一休.comさん、Reluxさん、そして楽天トラベルと、オンライン旅行サイトのエンジニアが集まってパネルディスカッションをするというもので、 正直、始めにお話を頂いた時は、「それ、誰か聞きに来てくれるの…?」という感じだったのですが… 会場に対しては少し少なめではあったものの、多くのお客さんに来場していただけました! 旅行ECサイト各社に聞く成長の秘訣とこれから #cross2015a - NAVER まとめ 私自身は初めてのパネルで、 常に回答を考えながら、そして「これ言っていいんだっけ?」も考えながらで、 結構表情がひきつりな
昨日知って感動した表現。これで、「はじまり」を含む行から「おわり」を含む行までを抽出できます。 たとえば、こんな hoge.html があったときに(h1が複数行に渡るってあんまないか、、、 でもあったんだよぅ) … <body> <h1> <a href="hogehoge">サンプルページのタイトルだよ。</a> </h1> <div class="text"> この辺から本文っすかね … $ sed -n -e "/<h1>/,/<\/h1>/p" hoge.html とやると <h1> <a href="hogehoge">サンプルページのタイトルだよ。</a> </h1> こうなります。 始めはどういう理屈かぜんぜん分からなかったのですが、 sedの条件式の 行数,行数⇒ 指定した行数間の文字列を処理する。 の応用なんですね。 /はじまり/ と /おわり/ が実はそれぞれ行数を返
表題のような感じなのですが、これまで理解が曖昧だったUnicodeとか何とかが今までよりわかったのでメモ。 尚、こちらのサイトを非常に参考にさせていただきました。 Unicodeについて コードポイントとは 文字コードとは 今日覚えた単語その一。Unicodeに限らず、文字をコンピュータ上で表現する際、1つの文字に1つの数値を対応させるわけですが、この文字に対応する数値をコードポイントというそう。 いままでASCIIコードとか呼んでました。 そして、文字と数値の割り当てのルールのことを「文字コード」と言うんだそうです。 Unicodeとは から UTF-XXは何が違うんじゃ という話へ Unicode誕生 文字コードが乱立したため、あるコードポイントで表現される文字が、文字コードによって、てんでばらばらという状況に。 ややこしいから、ひとつの統一した文字コードをつくろう! ということで「U
半年前のTDD Boot Campでの気付きだけど、改めて。 ※これを読んで、「いや、相変わらず誤解してるんですけどww」 と思われた方は是非ご指摘いただけると幸いです…。 1. 先にテストを書けばTDDなんでしょ? ⇒リファクタこそがTDDの命! Red -> Green はまだ入り口。そのあといかにRefactorしていくかが大事。 2. 最初に全ケース網羅するテストを書かなきゃなんでしょ? ⇒TDDで書くテストコードは設計のための作業なので、必ずしもそうじゃないと思う。 ただし、それとは別に、「変更に対してコードを守る」ためのテストは整備したいので、 後でもいいから最終的にはケースは網羅してほしい。
社内で、Jim Coplien氏による、2日間のスクラムマスターの研修を受けさせてもらう機会をいただきました。先週のJavaOneに続いて、会社からすごいお金と時間を出してもらってるなぁ…自分。 なかなかショッキングな内容も多く、整理するのに時間がかかりましたが、まとめと、今後のアクションを書いていきたいと思います。 用語:PBIとSBI 初めに今回覚えた用語を二つ。PBIはProduct Backlog Item, SBIはSprint Backlog Itemの略です。 概念的にはすでに馴染みのあるものですが、PBI、SBIという呼称は今回始めて知りました。 私は「スクラム」を理解していなかった さて、本題です。研修の一番冒頭で、Jimから、スクラムのたった一つの約束が紹介されました。 "It promises only that the team will work on the m
ほぼ発売と同時に買ったにもかかわらず、ずっと積読本になっていた「JUnit実践入門」をようやく読んでいます。 ここ最近で、バグによるリリーストラブルがあったり、単体レベルのバグがQAでボロボロ出てきたりということがあったため、改めてテストコードの品質(テストとしての品質はもちろん、可読性やメンテナンス性も含めて)について考えていたのですが… もやもやしてたこと、ほとんど書いてあるじゃん! ぐぅ、もっと早く読んでいればよかった。 レポートの前に、現状の問題 自分の書いたものも含めてなのですが、いまの身の回りにあるテストコードの多くにおいて、可読性が低く、何をしているテストコードなのかわかりにくい という問題が見られます。 (そうでないものも多くあります) 自分なりに原因分析をすると、以下のような原因が見られます。 テストメソッド名に意味がなく、コメントも無いので、何をするテストなのかよくわか
Simon Maple氏による、「CON4117:The Adventurous Developer's Guide to Application Servers」のレポートです。 とりあえず中身の前に外見の感想 いきなり映画のオープニング風味のムービーで始まった本セッション。 会場からアンケートをとってその場で棒グラフが書かれる会場参加型(?)で楽しかったです。 演出面では今回聞いたセッションの中で一番かも。 内容は仁義無きApplication Server Buttle! Application ServerをMaple氏独自に比較していくセッションです。出場は、Tomcat、Jetty、GlassFish、Liberty Profile、JBoss。の5者。(+WebSphereとWebLogicが最後に一瞬だけdisられに登場) なお自分の経験は Tomcat ⇒ いつもお世話に
うちの会社のアジャイルコーチな@kawagutiさんに誘っていただいたのがきっかけで、 San Francisco Agile 2012というカンファレンスに3日間、参加しました。 ※もちろん(?)会社にお金出してもらってます。 なんと今年は、エンジニア全員を海外カンファレンスに行かせる! と 昨年末に社長が宣言されたので、乗っからせてもらってます。ありがたいことです。 海外のカンファレンスに参加するのは初めてで、ドキドキと試行錯誤の連続でした。 が、3日間のセッションを通じて、自分なりの「海外のカンファレンス参加の形」みたいなものが、なんとなくできてきました。 ということで、記憶が薄れないうちにそれを書き留めておきたいと思います。 1. もちもの 3日間出てみて、必要だと思ったものを並べてみました。 ・PC メモ、辞書、SNS、ちょっとした調べもの用。 -メモ:手書きより速いです。自分の
このページを最初にブックマークしてみませんか?
『エンジニア的なネタを毎週書くブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く