2018/10/15 に JSLounge の活動として UUUM株式会社様で行った発表のスライドです。
「ようこそ 魔境 SIerへ!」 はじめに この記事は、SIer(Systems Integrator)に入ったシステム開発未経験者の新人さんたちへ送る、研修では教えてくれないノウハウ集です。 実際、弊社の長い研修では実務に使えそうなことをあまり教えてくれませんし、ノウハウは現場の人の頭にしかない状態なので、新人さんは暗中模索で仕事を覚えていくことになります。 それも非効率なので、実際に私が2年半1で失敗したこと、やってきてよかったこと(ノウハウ)を体系化したので共有します。 新人さんは、これを参考として、使えるところだけ今後の業務に持っていってください。 (本当はガッツリ社内向けに書いたものなので、一部汎用的でない表現がありますがご了承ください。) 目次 業務面 技術面 プライベート面 の三本柱でお送りします。 対象読者 SIerの1,2年目相当であり、学生時代に契約のあるシステム開発を
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」(よりよい代替がある)というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
新人プログラマのうちに身に付けたい習慣(この半年で学んだことと反省) はじめに 半年よりちょっと前に未経験からプログラマになりました。 プログラマと言っても、この約半年間はほとんど研修を受けさせていただいていた感じなので、偉そうなことは言えません。 しかし、この約半年で反省したことや学んだことを自戒の念も込めて、まとめました。 主体的に学ぼう 能動的に自ら学び、自走しましょう。 新しい技術を学ぶということは非常に楽しいことです。 すごい先輩方は大抵、新しい技術を身につけるためにその技術を学ぶことを「その技術を勉強した」というよりも、「その技術を使って遊んでみた」と表現している気がします。つまり、必要だからしょうがなく学ぶのではなく、半ば趣味として新しい技術で遊んでいたら、身についたーという感じでしょう。 教えてもらって学ぶという姿勢ではなく、自ら楽しいから学ぶ(=その技術で遊んでたら身につ
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
はじめに autovivificationを避ける myと後置ifを同時に使ってはならない return;で返る値は空のリスト 正規表現によるバリデーションでは\Aと\zを使おう '0' は偽で評価される each は中断した時、中断した時点の状態が残り続ける おわりに はじめに こんにちは。アプリケーションエンジニアの id:t_kyt です。 春です。Perlを始めるにはいい季節ですね。Perl始めていますか? どの言語にもハマりどころというものがありますがPerlも例外ではありません。というわけで今回はPerlを始めた人がハマりがちなポイントを幾つか紹介したいと思います。 この記事ははてなの教科書程度の知識を前提としています。またモジュールに依存しない部分に絞りました。 github.com autovivificationを避ける autovivificationとはundefの入
10 golden rules for becoming a better programmer | codeshare.co.uk .Net Web Developer Blog by Paul Seal この手の記事には食傷気味だが、学ぶべき教訓には学んだほうがいいわけで、果たしてここではどんな10個のルールが示されているのか。 同じことを繰り返さない(コードのリファクタリングの勧め) 変数には、それがどんな型かではなく、それが何のためにあるか分かる名前をつける メソッドには、それが何をするか明確に分かる名前をつける マジックナンバーや文字列リテラルは使わない 可能であれば、メソッドはそのアプリの他の部分に依存性を持つことなくテストできるよう書く 助けを求めるのを恐れない(やってることを他人に説明するプロセスが問題解決につながることもある) ボーイスカウト・ルールに従う(バグのあるコー
はじめに ネットには様々な情報が溢れており、JavaScriptに関する情報も多数存在しております。 その中には、「今時こんな書き方しねえよ…」と思わずツッコミを入れたくなるような、本当に、本当に古い内容について書かれている古文書も存在します。 そんな罠記事の情報に囚われてしまって、いつまで経っても現代的なJavaScriptが書けない皆さんのために、このシリーズの記事では、各セクション毎に分けて、旧石器時代の記述と、現代の記述を紹介する形で、文明開化をしていきたいという思いで記述する。 最初は、現在比較的メジャーなブラウザで一通り動作する「ECMAScript 5」までの内容に関してポエムを書き連ねていき、最終的には一連の内容を読むだけで「ES6(ES2015)」による新機能や、絶賛提案中の「ES7」の一部提案内容についても把握し、おおよそ現代人を育成することを目標とする。 …なんてめっ
2016年個人的に注目したいというか力を入れたいというか成行を見守りたいというか、そんな技術達を書き連ねていく。ものによっては「何を今更」と思うかもしれないがあくまで私にとって、だ。 順不同。 Apache Drill 公式。様々なデータソースに対してANSI SQLでクエリを投げれるやつ。 ビッグデータの時代にETL無しで迅速にデータを分析出来るようにするために開発されてるらしい。 様々なデータソースというのは本当に凄くて、CSVとJSONをJOIN出来たりする。 あるいはTSVの生ログとRDBにあるマスタデータをJOIN出来たりする。 個人的にはデータベースから抽出したCSVにクエリを投げたい時に便利かな、と思って注目してる。viewや一時テーブルを作る権限がないデータベースだってある。 あるいは、Zookeeperを使って分散モードで実行も出来るのでBigQueryみたいなのをオンプ
今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニアとは何なのかについて、今年一年で考えたことを書いてみたい。 良いエンジニアとは何だろうか。技術力が高ければ当然に良いエンジニアと言えるのだろうか。そもそもエンジニアに必要なスキルとは何だろうか。技術力がまず挙げられるだろう。良いエンジニアは当然に高い技術力を持っていて生産性が高いはずだ。 技術力に加えて、プロジェクトマネジメントのスキル(以下プロマネ力と省略)も必要なのではないだろうか。これまでの自分の経験を振り返るに、技術的に秀でたエンジニアはプロマネ力も兼ね備えていることが多いと感じる。技術力が高いエンジニアはプログラミングの能力が高いので、組織や開発体制を「プログラム」する能力が培われるのかも
漢は黙ってシングルファイル C/C++ ライブラリですね! シングルファイル C/C++ ライブラリとは, ヘッダファイル .h ひとつだけで機能が実装されているライブラリ(もう少し条件をゆるくして .cc も含む)のことです. header-only とも言われれたりします. このあたりの元祖は nothings 先生 http://nothings.org/ ですね. 最近は github にコードをあげています. https://github.com/nothings/stb シングルファイル系のライブラリまとめ一覧もあります. シングルファイル系が便利すぎてやばいので, 自分でもいくつか作りました. TinyObjloader(Wavefront .obj loader) https://github.com/syoyo/tinyobjloader TinyEXR(OpenEXR
これはほとんどネタです。 ここ最近、マルクスを再読していました。貧富の格差、貧困の問題とかワーキングプアーなどがニュースになっていることを見るにつけ、マルクスが気になっていたからです。マルクスが資本論を書くための準備していた時期の『経済学・哲学草稿』などに、貧富の格差、ワーキングプアーといった今とまったく同じ問題が記述されていたので、マルクス経済学は超克したとかいいつつ、実は全く何も超克していないのだと思いつつ有ります。 時折、話題になる労働に関するテーマなどがあり、それらについてもマルクスの著書ですでに述べられていることがあったりします。 例えば、エンジニアが勉強し続けることについてです。 今年、このことの元になった記事はこれだと思います。 101回死んだエンジニア: 業務時間外で勉強をしなければいけない理由 簡単にまとめると、技術者は技術だけが武器であり、それが通用しなくなると歪んだ環
Photo by Indi Samarajiva こんにちは、谷口です。 「ITエンジニアは業務時間外にも勉強をすべきなのか」という問題について、皆さんはどう思われますでしょうか。 少し前には、こちらの記事も話題になりましたね。 業務時間外で勉強をしなければいけない理由:101回死んだエンジニア:エンジニアライフ 今回は、そんなITエンジニアの業務時間外での学習について考察していきたいと思います。 ■企業からの「教育」と自分でする「学習」 業務で必要な知識等について、企業側もある程度は「教育」をすることがあるかと思います。特に新卒の場合、新人研修として業務知識を学ぶ期間が多くの企業で設けられているかと思います。仕事で必要な業務知識に関しては、企業の研修を受けるだけではだめなのでしょうか。 まずは、「教育」と「学習」の概念について考えてみましょう。 「教育」とは、組織の求めるスキルを個人に習
「開発スピードをあげろ!」と言われる事は多々ある。 実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず!」と人を追加する。しかし、根本的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。 開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。 例えば、「仕様決め」の問題点は 仕様が決まらず、MTGの時間が長い 仕様を決める人がいない 誰かに確認する事が多い 開
NOTE: 本記事はすでに内容が古く、今読んでも役に立つ度合いはほぼないです。 本記事は、先日社内勉強会のために準備した、Webサービスのリアルタイム通信周りのまとめシリーズ の1つを転載して公開するものです。 まだまだわかっていないことが多いので、ぜひぜひ間違っている点などにご指摘いただければと思い公開します。 ぜひぜひ優しくマサカリをいただけると泣いて喜びます! 目次 目次 はじめに プロトコルと手法 前世代のやり方であるComet について Polling 系 Streaming 系 過渡期といわれてる手法 将来有望といわれてる手法 Polling メリット デメリット 向いているシーン Long Polling (Comet) Polling の発展版 メリット デメリット LongPolling 自体は双方向通信ではない 接続が閉じられるケース 向いているシーン Server S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く