イマドキのJavaScriptの書き方2018
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
VRで「結月ゆかり」になって生放送する - Qiita
#はじめに どうも@toRisouPと申します。ドワンゴにてニコニコ生放送（新配信）の開発を行っています。 皆さんはニコニコ生放送、利用されてますでしょうか？ 自分はたまに生放送を行っています！ 自分が配信する放送のうち8割はゲーム配信なのですが、残り2割は思いついた技術ネタを作ってみて生放送で実演するという内容になっています。 今回は自分の過去のネタの中から1つピックアップして紹介したいと思います。 #ゆかりごっこ 「ゆかりごっこ」は過去に自分が行った生放送の中で一番好きなネタです。 成人男性の9割は美少女になりたいという願望があるはずです。 その願いを叶えるために、VRで結月ゆかりさんになれるアプリを作り、それを実際に使って行った生放送が「ゆかりごっこ」です。 具体的にどのような生放送を行ったかは以下のアーカイブをご覧頂けるとよいかと思います。 ゆかりごっこ1 ゆかりごっこ2 ゆかりご
OSSドキュメント翻訳を支える技術 (Keycloakを題材に) - Qiita
Keycloakドキュメントの翻訳ではどうしているかというと、3つ目のテキスト抽出した部分のみを翻訳の方式を採用しています。というのも、現状、毎月のように最新版がリリースされており、ドキュメントもどんどん変わっていく恐れがあると思い、変更に追随しやすい(はず)、翻訳者は翻訳作業だけに集中できる、という点から3つ目の方式を今のところは採用しています。 ソーステキストからのテキスト抽出について 方式3を取る場合、テキスト抽出を行い、翻訳後に元のテキストにマージする仕組みが重要になってきます。というわけで、次はテキスト抽出について述べます。 翻訳対象のソーステキストフォーマット テキスト抽出を行うためには翻訳対象のソーステキストフォーマットが重要なポイントになってきます。OSSドキュメントで利用される代表的なテキストベースのドキュメント作成ツール/マークアップ言語としては以下があります。 Asc
Android機種依存動作まとめ - Qiita
この記事はRetty Advent Calendar 2017 における 11日目の記事です。 昨日は @tkngue のデータベースレス で サーバーレス な 社内図書システムをGoogle App Script (GAS) で作ってみる でした。 はじめに RettyでAndroidエンジニアをやっている福井です。 Android開発をしていている皆様、いかがお過ごしでしょうか？2017年も終わろうとしていますが相変わらず機種依存と戦っていることだと思います。私は戦っています 機種依存はAndroid開発をする以上避けて通れない問題かと思いますが、なかなか一覧でまとめられている記事を見かけない気がしたので作りました。Rettyに入社してからの2年半で私が出会った機種依存のあれこれです。それではどうぞ。 機種依存挙動 AQUOS かつ OS ver 4.1.2 android:windo
Macに別れを告げて、クラウド中心の開発生活を始めるまで - Qiita
昨年あたりから、Macやめたい病を患っていたのですが、2度の故障を経て、重たい腰を上げました。別にWindows使いたいわけもなく「ローカルが煩わしい」だけなので、Windowsアプリは一切インストールしていません。で、どうやって暮らしてるの? というお話です。 TL;DR このあたり↓を組み合わせていけば、クラウド生活可能: GCP (or AWS) Codeanywhere (or Koding or Cloud9) VPCネットワーク + VPN (IPsec+L2TP) + DNS Figmaほか、Webサービス各種 追記・この記事を書いていたら、AWS Cloud9が発表されました。選択肢が増えて何よりです。 はじめに 本稿は、筆者が「Mac断ち」あるいは「ローカルマシンから解脱(げだつ)」する過程で見えてきた、ベスト(かも)プラクティス集に近いものです。 よく使うテキストエディ
郵便番号や市区町村データを取り扱うときにはまったこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今とりかかってる案件で、郵便番号から自治体を特定して云々という処理をやっているんですが、いくつかはまりポイントがあったので備忘録的にポストしときます 自治体コードは6桁のものと5桁のものがある これはすごく単純なお話で6桁のものは最後の1桁はチェックディジット 残りの上5桁から機械的に計算できます 郵便番号は必ず1つの町名に紐づいているわけではない 郵便番号→住所入力というフォームを作るときにハマる 例）郵便番号 807-0042 福岡県 遠賀郡水巻町 吉田 福岡県 遠賀郡水巻町 吉田団地 私の住んでいる宮城県にも 例）郵便番号 981
技術の中心でJavaを叫ぶ -2017年のJavaエンジニアが追うべきテーマと要素技術- - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? かつてJavaは技術の中心だった 私はSIerでシステム開発のアーキテクトやPMを担当しています。SIではまだまだJavaが主流ですが、文法を理解してコーディングできるだけでは活躍できない時代がすでにきていることを実感します。 私の上司が**「技術の渦」**という独特の表現を使って説明してくれたのですが、2000年から2006年ぐらいまではJavaを書くということは、いろいろな最新技術の実装を学べる時代でした。アプリケーションサーバー、XML、SOAP、MQ、CORBA、マルチスレッドなど、現代の評価としては芳しくないものも多いですが、
阿部寛とは？開発に役立つ使い方、トレンド記事やtips - Qiita
阿部寛に関する情報が集まっています。現在26件の記事があります。また55人のユーザーが阿部寛タグをフォローしています。
dev.toと阿部寛のホームページについてちゃんと計測させてくれ - Qiita
Twitter見てたら、以下のツイートを見た。 数時間後、dev.toと阿部寛のホームページどっちが速いですか？というブログがTLに現れた。 GoogleのPageSpeed Insightsで測って阿部寛のホームページの方が早かったという結論付けてよいのかという疑問が浮かび、webpagetest.orgで計測することにした。 設定 阿部寛のホームページに関しては、Tokyoリージョンにあるものとする。 そして、dev.toはNY発らしいので、サーバーの設定をNYにして測定する。 The platform was created in 2016. The twitter account, @ThePraticalWeb 評価結果 Webpagetest - 阿部寛のホームページ Webpagetest - dev.to 阿部寛のホームページ サーバーからのレスポンスの圧縮がされておらず、
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬
フロントエンドチェックリスト（日本語訳） - Qiita
GitHubで公開されているフロントエンドチェックリストというドキュメントが、網羅されている内容が幅広く便利そうだったので、日本語に翻訳しました。 日本語版は、以下のGitHubリポジトリにあります。GitHub側と自動的に連携するようにしておりますので、誤訳や誤りなどがあれば GitHub のプルリクエストまたは Issue で報告していただけると幸いです。 https://github.com/miya0001/Front-End-Checklist 日本語版への貢献方法 最終更新日時: 2017-11-19 03:50:47+09:00 (未翻訳) Front-End Checklist The Front-End Checklist is an exhaustive list of all elements you need to have / to test before lau
15週間でクソゲーを20本作って得たもの - Qiita
5の「振り返り」は以下の項目を検討しておくと良いです。 Idea：アイデア。コンセプト。テーマ。元ネタ What went right：やってみて良かったこと。うまくいったところ。成功したところ。次回に生かせそうなこと What went wrong：ダメだったところ。うまく機能しなかったところ。問題点。改善すべき点 What I learned：学んだこと。効果的なゲームデザインの方法やツールの使い方、獲得したテクニックなど ちなみに最初にリンクを貼った、作ったゲームの各ページの下の方には、振り返りや作成にかかった時間などを記載しています（以下はノンフィールドRPG「OneWay RPG」を作った時の振り返り) Game A Weekで得たもの ということで「Game A Week」を行った結果、私が得たものです。 ゲームを作りながら技術検証できる ゲームを完成させたときの達成感を繰り返
優秀な技術者を追い出してしまう方法 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのか
やばい、iOSにネイティブアプリ要らなくなるかも。SafariもPWAに対応する可能性 - Qiita
これ以上は長くなるため後述． ##Chromeは既に，Safariもようやく 上記の通り，Service WorkersがPWAでも最重要な機能の一つである．Chromeでは既に対応済み． しかしSafariが対応しておらず，世間的にはモチベーションの上がらない状況であった（やちまもその一人である）． Safariにおいて，Service Workersの実装状況 No active development が Under Consideration になったのは2015/12/041のことである． 20ヶ月という永遠とも呼べる時を経て，2017/08/032にようやく In Development となったわけであった． ##だから何なのか SafariにService Workersの実装がなされると，一気にウェブアプリへの移行が進む可能性が大きい． ブラウザの制約が弱まり，ウェブアプ
あなたのおっしゃるレビューってどのことかしら？ - Qiita
ソフトウェアのレビュー ソフトウェアの開発において、レビューが品質の確保をするために有効であることは私達は直感的、経験的に理解しています。 人は間違いを犯しますし、間違った本人よりも他人のほうが誤りを見つけ易いものです。 ここまでは、認識を共通できるものでしょう。 しかし、レビューと一言で言った場合に、その実態にかなりのギャップが生じます。 ある人にとっては、気の合う同僚とコーヒーでも飲みながら成果物をチェックしてもらう事かもしれません。 しかし、別の人にとっては会議室で衆目の前で細かい所を吊るし上げられる苦行のことかもしれません。 ある人にとっては、口で簡単に説明するだけかもしれませんし、メールやツールでコメントを書くだけかもしれません。 しかし、別の人にとっては、準備の為に大量の資料を作り、終わった後にも大量の報告書を書く事かもしれません。 プロジェクトを初めて、レビューといった場合、
プログラミングでよく使う英単語のまとめ【随時更新】
チェックマークをつける意味で check を使う場合は例外。 check 自体を避けたい場合は putCheckmark とする。 change 何をどう変更しているのかわからない。 check と同様に具体的な名前にできないか考えてみるとよい。 例外として isChanged のフラグを変更するための Change メソッドに使う場合がある。 xxxManager / xxxController こういう名前をつけるとクラスが肥大しやすい。 単一責任の原則にのっとってクラスを設計するべし。 UNIX 哲学にも「Small is beautiful.」という考え方がある。 xxxType, xxxData, xxxItem, xxxInfo 冗長になりやすい。 Type, Data, Item, Info を取っても意味が通じないか検討してみる。 使わないほうがよい言葉 compare 比
ブロックチェーン技術は本当に有望なのか？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? （2017年6月時点において）ここしばらくでのブロックチェーン技術の盛り上がりには圧倒される一方で、いざ、その技術的な実装内容について調べると共に、期待と現実との間での若干のギャップにとまどうところもあります。この記事ではそうした（個人的な）とまどいの内容を、「ブロックチェーン技術の有望性」という命題を軸とする形で、簡単な解説を交えつつ共有させていただきます。 （本記事の筆者と同じく）「熱狂の只中にあるブロックチェーン技術に飛びついて良いものか？」と自問されている各位にとっての参考としていただければ幸いです。 #本記事のまとめ ブロック
あっと驚かせるJavaプログラミング(をやめよう） - Qiita
はじめに 驚き最小の原則（法則）という言葉があります。 Wikipediaの記事を引用すると http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87 ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。 要するに、使うときに「おやっ？」という驚きが少ないほうが良いプログラムであるといえます[1]。 [1]: どっちが驚きが少ないか迷う場面もかなり多いですが・・・ この記事では敢えて驚きの多いプログラムの書き方を紹介します。驚きの多いプログラムを読むとどんな気分になるか、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ひとりでCPUとエミュレータとコンパイラを作る - Qiita Advent Calendar 2017 - Qiita
