ブックマーク / qiita.com (61)

  • [あるある]「詰まったら、すぐに質問してください」の克服法 - Qiita

    はじめに 「詰まったら、すぐに質問してください!」 こう上司PM、先輩エンジニアの方から言われたことありませんか? これを言われるのはおそらく初学者の方だと思いますが、以下のような経験はありませんか? わからないことが発生した! 「すぐに」質問してと言っていたので、文意のまま即座に質問した・・・ ( ゚д゚) <「少しは自分で調べたのか!」1 と一蹴!!!チーン(´・ω・`) (すぐ質問してって言ってたのに・・・(´;ω;`)) 自分で調べれば良いのか、ふむふむ。。。 わからないことが発生した! 自分で限界まで考えて調べてみても、まだわからない・・・ (数時間経過後)恐る恐る質問した・・・ ( ゚д゚) <**「最初のうちは考えても仕方ないこともあるから、すぐに質問して!」**と一蹴!!!チーン(´・ω・`) 「いったいどうしたらいいんだぁぁぁぁぁぁぁぁああああああああ!!!!!!!!」

    [あるある]「詰まったら、すぐに質問してください」の克服法 - Qiita
    junpeso
    junpeso 2019/10/04
    ポエム
  • ソシャゲエンジニアの自分が開発に必須だなと思った知識(MySQL編) - Qiita

    この記事の目的 自分は、とある会社様の元でソシャゲAPI 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC

    ソシャゲエンジニアの自分が開発に必須だなと思った知識(MySQL編) - Qiita
    junpeso
    junpeso 2019/09/25
  • GitHub Actions で Windows IE11 と Mac Safari を selenium-webdriver で動かす - Qiita

    GitHub Actions で Windows IE11 と Mac Safari を selenium-webdriver で動かすSeleniumselenium-webdriver 最近得た天啓で、 「GitHub Actions はコンテナを windows / mac / ubuntu から選べるということは、 物の safari と ie11 を selenium-webdriver で動かすことができるのでは?」 と思ってガチャガチャやってみたら、なんとできてしまったので、紹介します。 今回は node で。 name: xbrowser on: [push] jobs: e2e-ie: runs-on: windows-latest steps: - uses: actions/checkout@v1 - uses: warrenbuckley/Setup-Nuget@

    GitHub Actions で Windows IE11 と Mac Safari を selenium-webdriver で動かす - Qiita
    junpeso
    junpeso 2019/09/20
    気づいてしまったか
  • エンジニアないない - Qiita

    「あるある」じゃないです はじめに これは、筆者が周りの非エンジニアの方々に 「エンジニアの人って◯◯なんでしょ?」 と言われて、「いやそんなことないですよ笑」と答えた話をまとめました。 この回答が、同じような質問を受けた人が 「ないない。実際はこうなんだよ」 と答える参考になれば幸いです。 (どんな時だよ!) 自分の経験値だけで語っているので、 「俺の場合はあるあるだよ!」 とかあるかもしれません。ご了承ください。 色んな「ないない」 ハッカーって銀行に侵入して口座の金額増やせるんでしょ? ないです。 振込はネットでもできますが、トランザクションの登録だけであり、 実際の金額の操作はネットワークから分離されています。無理です。 インターネットからできるのはキューの登録だけです。 基幹システムでチェックされるので、例え不正な振込データを送信できたとしても 実際に反映される時に弾かれます。残

    エンジニアないない - Qiita
    junpeso
    junpeso 2019/09/12
    ポエム
  • SIerに生息する「おじさんSE」の生態を知る - Qiita

    ここでいうおじさんSEとは、主にSIerに生息する、 ・30歳以上で ・モダンな技術を知らない ・レガシーな技術しか知らない ・主に設計書などのドキュメント類を弄っており、コーディングをしない ・現状から変わる気がない(キャリアアップに対し具体的なアクションがない) 人たちを指す。 決して単に妙齢のエンジニアを一括りにしているわけではない。 「おじさんSE」より良い呼び方があれば、ぜひご提案いただきたい。 第1章 おじさんSEの仕事内容 おじさんSEは、コードを書くことはほぼ無い。 これは現場にもよるので、全く無いというわけではないが、 多くのおじさんSEはコーディングはしない。 ではおじさんSEは何をやっているのかというと、 ・内部設計書、外部設計書、詳細設計書の記述 ・結合試験以降の試験項目票の作成 ・試験結果のレビュー 大抵はこの3つになる。 99.9%はウォーターフォール型である。

    SIerに生息する「おじさんSE」の生態を知る - Qiita
    junpeso
    junpeso 2019/09/11
    ポエム
  • Reactを使ったモダンなフロントエンド開発の環境構築 - Qiita

    はじめに Reactを中心としたフロントエンド開発において、以下のような構成を見かけることが多いと思います。 UIライブラリとしてReact 型のある言語としてTypeScript スタイル定義としてstyled-components コンポーネントの開発環境としてStorybook LinterとしてESLint FormatterとしてPrettier この記事では、各種ライブラリについて紹介したのち、それらを使う場合の環境構築についてハンズオン形式で説明します。 ※ アプリケーションを開発する際に必要になる設定が抜けていたので、追記しました。 各種ライブラリの紹介 まず、各ライブラリがどのようなものなのかを簡単に紹介します。 ライブラリの使い方などは公式ドキュメントなどを参照するようにしてください。 ドキュメント ReactUI(ボタンやフォームなど)コンポーネントを作成するための

    Reactを使ったモダンなフロントエンド開発の環境構築 - Qiita
    junpeso
    junpeso 2019/08/19
  • dockerでvolumeをマウントしたときのファイルのowner問題 - Qiita

    dockerでvolumeをマウントするときの問題点 docker runするときに-vオプションをつけることによってホストのディレクトリをコンテナ内にマウントすることができる。 ホスト側のファイルをコンテナ内で使いたい場合や、逆にコンテナで作ったファイルにホストからアクセスしたい場合に有用なのだが、ファイルのアクセス権限についてちゃんと考えておかないと問題が起きることがある。 例えば、ホスト内でのユーザーのuidが500だったとしよう。 $ id uid=500(ec2-user) gid=500(ec2-user) groups=500(ec2-user),10(wheel),497(docker) $ mkdir -p temp && touch temp/foo # 実験用に適当なディレクトリを作ってみる $ docker run -it -v $(pwd)/temp:/temp

    dockerでvolumeをマウントしたときのファイルのowner問題 - Qiita
    junpeso
    junpeso 2019/07/09
    せっかくステートレスに作ってるのにwritableでvolumeをマウントするといろんな問題が噴出するので嫌い。ローカル確認ならローカルでもコンテナでも動くコード書いたほうが健全だぞ。ローカルで動かすことを諦めない
  • 「コメントは書くな」 - Qiita

    同僚だったロシア人のMはとにかくすごいエンジニアで、給料について社長ともめていたかと思えば、スーパーデプロイシステムを一人で作り上げていたり、Python推しの会社の中で、各所を説き伏せてTypeScript on node.jsの導入を進めたりしていた。 皮肉屋で、だれかれかまわず議論をふっかけていたが、とにかく仕事が速くて品質がよいので絶大に信頼されていた。 私は開発者としてMから様々な教えを授けられた。当時私はPHPerあがりのひよっこで、日々ダメコードを生産していた。 ある日Mにコードレビューを依頼すると、こんなことを言われた。 「堀さん!ソースコードにコメントを書いてはいけない!」 // connect to the database named "mysql" on the localhost val driver = "com.mysql.jdbc.Driver" val u

    「コメントは書くな」 - Qiita
    junpeso
    junpeso 2019/07/01
    コメントいるいらない、無くても理解できるできないは糞主観に過ぎないのでかってにしろと思うけど、動的型付け言語なんだからせめてYARDかRubydocは標準化しろ
  • slackで「投稿ルールが守られない問題」を自作のスラッシュコマンドで解決する(設定編) - Qiita

    slackあるある ※※お知らせ※※ 今後、備品購入を希望される方は当チャンネルで ================ 【購入品名】 : 【購入URL】 : 【購入承諾者】: 【納品希望日】:2019/mm/dd 【備考】   : ================ というフォーマットを使って下さい。 (ピンどめしておきます) 現実は・・・ フォーマットを自己流に改変する人 そもそもフォーマットを使ってくれない人 別のチャンネルで依頼する人 etc..... 解決策 今後、備品購入依頼は 当チャンネルで /bihin と投稿し、 表示されるダイアログから依頼して下さい。 表示されるダイアログ 簡易バリデーションチェックあり ダイアログ経由で生成される投稿 確実に期待したフォーマットで投稿してもらえる 指定のチャンネル以外でコマンドを使用した際のエラー表示 投稿者人だけにエラーが通知され、無駄

    slackで「投稿ルールが守られない問題」を自作のスラッシュコマンドで解決する(設定編) - Qiita
    junpeso
    junpeso 2019/06/16
    freeeとかのがよくない?
  • レガシープロジェクトを引き継いだ時、最初にするべき7つのこと - Qiita

    営業一課で使っている PHPアプリを保守してくれないかな? ○○さんが1人で作ってメンテしてたやつなんだけど 皆さんは上司からこんな仕事を振られたことはないでしょうか?私は過去に何度か経験した1のですが、こういった仕事はなぜか: 正確な仕様を知っている人はいない(知ってた人は辞めた) テスト計画書・デプロイ手順書・仕様書といったドキュメントは無い ソースコードはもちろんスパゲッティ でも、業務ではガッツリ使われているので廃止できない というレガシープロジェクトばかりでした。この記事では、レガシープロジェクトを引き継いでしまった時に、最初に何をするべきか書いていきたいと思います。 なお、ここで最悪なのは「とりあえず、緊急の不具合から直してしまおう」と、いきなりコードの修正にかかることです。 ※おことわり: この記事では「遵法的な職場の」「PHPRailsで書かれた」「社員25人が使う」「業

    レガシープロジェクトを引き継いだ時、最初にするべき7つのこと - Qiita
    junpeso
    junpeso 2019/05/24
    ブログに書け
  • 文科省のPythonはPythonじゃねぇ - Qiita

    TL;DR 文科省によるプログラミングの教材はダメダメ。PEP8読め。 追記 もちろん、この指摘が普通のコードに対するものだとすれば 「重箱の隅をつつきすぎ」 だというのは全くその通りだと思います。こんな指摘をするつもりはさらさらありません。 しかし、これが文科省という権威ある機関が発表するものならば話は全く違います。 全ての日教育を一身に背負うくらいの気持ちと成果を伴わなければならないとも思います。 そういう理由での、厳しい(というか細かい)指摘です。 追記2 自分の説明が足りませんでした(すみません)。ちなみにこの教材は「教員研修用」です。 この教材で研修を受けた教師にプログラミングを教えられると思って考えてみてほしいと思います。 追記3 (2019/9/25 文科省の改訂を受けて) この度文科省がPythonに関する資料の改訂版を発表しました。 文科省に対して改善を求める当初を行

    文科省のPythonはPythonじゃねぇ - Qiita
    junpeso
    junpeso 2019/05/21
    平易に教えることは重要だけど嘘は教えないほうがいい
  • Rubyは死んだというが。流行り廃りに拘らず、便利なものは活用すればいいのに - Qiita

    はじめに:Rubyは死んだらしい。便利だけどな~ ここ一年で技術的な情報を意識するようになったからか、言語マウントが気になるようになりました。Rubyは死んだ、Javaはオワコン、Goは70年代に立ち往生した言語だ、Cは化石だ。 こういった話題を見る度にずっとモヤモヤしてしまいます。どの言語も一長一短あるんだから、0か1かで語らずいいとこどりで活用すればいいのにね。 今回はRubyが叩かれていたので、擁護してみました。 いいところの前に 私のRuby歴 業務で2年程使っていました。Ruby On Railsは触ったことがなく、主にcgiやmruby、テストスクリプトとして利用していました。 それ以外の言語として一番長いのはC。加えてC++PythonJava趣味Goに触ります。 また、Linux開発メインなのでbash(shell script)もよく使います。 備考 ※記事はR

    Rubyは死んだというが。流行り廃りに拘らず、便利なものは活用すればいいのに - Qiita
    junpeso
    junpeso 2019/03/11
    廃るとgemもメンテする人減るのでgemに頼らないといけないrubyは便利じゃなくなる
  • JavaScriptの関数名の全て - Qiita

    JavaScriptに限った話ではありませんが、関数というのは名前を持っていたり持っていなかったりします。関数名は普通はプログラムの読みやすさくらいにしか影響しませんが、JavaScriptでは必ずしもそうではありません。 例えばReactで関数コンポーネントを使う場合は関数名がコンポーネント名となり、React用開発者ツールなどで見ることができデバッグに役立ちます。また、Gulp v4もエクスポートした関数名がタスク名となります。 関数名は、関数オブジェクトのnameプロパティで取得できます。 function foo() { console.log('foo!'); } console.log(foo.name); // "foo"

    JavaScriptの関数名の全て - Qiita
    junpeso
    junpeso 2019/03/11
  • 量子コンピュータエンジニア始めて5年が経った - Qiita

    はじめに もともとふつうのベンチャーでしたが、2014年に量子コンピュータにピボットしてからはすくすく会社が育ち、向いてることをするのは大事だなと感じてます。 Qiitaはポエムを書かないといけないらしい(多分)ので。おそらく日初の量子コンピュータベンチャーとしてまず五年目までに気づいたことを書いてみます。 もともとはデザイン会社 もともとうちの会社はデザイン会社でした。出身が建築事務所だったので、そのまま2009年に独立してデザインをしてました。建築時代はphotoshop+autocadを使っていました。イラレはいまだに苦手です。 前の建築事務所は隈研吾建築事務所というところで、青山の美術館の設計や中国のアリババの社屋のコンペなどを主にしていました。 建築は当時CGパースも仕事がたくさんありましたので、CGのモデリングやレンダリングをやりながら当初は生計を立てていました。ただ、リーマ

    量子コンピュータエンジニア始めて5年が経った - Qiita
    junpeso
    junpeso 2019/03/09
  • 100名に聞いた!エンジニアリングマネージャーの給与と責務の実態調査 - Qiita

    はじめに ソフトウェアエンジニアリングマネージャ(以下、EM)に求められる責務は、多岐にわたっています。 流動性が高いITの業態である一方、日型メンバーシップ雇用と米国型のJD型雇用との隙間にあって、責務と権限の曖昧な状況の中に置かれることも少なくないように思われます。 このような状況下で、メンバーからも経営からも双方にそれぞれの考える理想的なマネージャであることを求められることもしばしばあるようです。結果として、マネージャの休職など精神的なストレスも高さが問題になっています。 また、ソフトウェアエンジニアにとって、プログラミングにおけるスキルとくらべ、マネジメントに対するそれのモビリティ(会社を変えても有効であると思える程度)が低く見えると言ったことから、ソフトウェアエンジニアにとってキャリア形成に効きづらいのではないかと考えてしまうことも自然なことです。 その結果、ソフトウェアエンジ

    100名に聞いた!エンジニアリングマネージャーの給与と責務の実態調査 - Qiita
    junpeso
    junpeso 2019/02/26
    ポエムタグお願いします
  • なんでもかんでも「バグ」ってひとくくりにしないで - Qiita

    はじめに プログラマがソフトウェアを作るとユーザがつきます。ユーザがそのソフトウェアを使っていて何らかの問題が発生すると「このソフトはバグってる、直して!」と言われることがままあります。それに対して「いや、仕様だから」と突っぱねられることがあります。その後お互いの意見が「バグだ!」「いいや仕様だ!」と平行線になってお互いモヤモヤのまま終わるというのはよくある話です。 なぜこういうことが起きるかというと、原因の一つは「問題」イコール「バグ」という短絡的な考え方です。とくにソフトウェアを作ったり使ったりした経験が浅い人がこうなる傾向があると推測しています。このようない違いは「要件」「仕様」と「実装」という言葉の意味を理解していればある程度解決できます。書はこれらの用語について実例を挙げて簡単に紹介します。 注意点 記事では要件や仕様を定義することが前提となっていますが、とくにユーザと開発

    なんでもかんでも「バグ」ってひとくくりにしないで - Qiita
    junpeso
    junpeso 2019/02/25
    そいつはバグじゃない。"ほっといてもいいバグ"だ。
  • 私たちはどうして公式ドキュメントが読めないのか? - Qiita

    少しプログラミングを覚えてきた初学者が、さらに力をつけるために必要なのが公式ドキュメントを読むことだと思います。 公式ドキュメントには、日語の記事には書かれていないような詳細な説明や、APIの使用方法、そしてリリースノートなど、実装には不可欠な情報が掲載されています。 しかし、公式ドキュメントが上手く読めずにつまづく人も多いのではないでしょうか?慣れていない人にとっては、技術について書かれたドキュメントを読むのは難しいものです。 この記事では、つまづいてしまう人が少しでも減るように、公式ドキュメントが読めない原因と対策をいくつか書いていきます。 公式ドキュメントとは この記事で言及している「公式ドキュメント」は、フレームワークやライブラリ、言語について、その公式組織が出している文書のことです。 具体的にはこのへん。 どうして公式ドキュメントが読めないのか 原因1. 公式ドキュメントを読む

    私たちはどうして公式ドキュメントが読めないのか? - Qiita
    junpeso
    junpeso 2019/02/13
    ポエムタグついてるねヨシヨシ
  • DNS over HTTPSの必要性について - Qiita

    なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ(フルリゾルバ)の(主に)UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ

    DNS over HTTPSの必要性について - Qiita
    junpeso
    junpeso 2019/02/13
    DNS over HTTPSを実装するDNSサーバのアドレスはどこから取得するの?
  • ネットワーク越しでパイプしたり、あらゆるデバイス間でデータ転送したい! - Qiita

    何を解決したいか? Mac, Windows, Linux, iPhoneAndroidのスマホ・タブレットとかのデバイス間でデータの転送したいことがあります。 SlackとかLineとかSkypeとかAirDropとかあっても 送りたい相手と共通して使っているサービスを探す必要とか、 GUIのソフトウェアのインストールが必要とか、 AirDropだとApple系OSである必要 があるなどの転送の障壁があって、GUIが使えないデバイスに送りたいときなどは困ってしまいます。 すでにたくさんのファイル共有系のサービスがありますが、コマンドを使ったCUIベースにあまり親切な設計なものはあまりないと思います。 そこで、上記の問題を解決するために、以下のようなファイル転送の仕組みを作りました。 他デバイス間でデータ転送ができ、 別途ソフトウェアのインストール不要で、 パイプにとても親和性が高くエン

    ネットワーク越しでパイプしたり、あらゆるデバイス間でデータ転送したい! - Qiita
    junpeso
    junpeso 2019/02/07
  • エンジニアは最初の会社を1年程度で辞めた方がよい理由 - Qiita

    「実務未経験からWeb系エンジニアにジョブチェンジする方法」に関しては、最近かなり広く知見が共有されるようになってきましたが、「Web系エンジニアにジョブチェンジした後の転職戦略」に関してはまだまだ有用な情報が少ないという印象です。 学生時代からプログラミング経験があり、レベルの高い有名Web系企業さんに新卒で就職できた方たちは別として、キャリアの途中でWeb系エンジニアにジョブチェンジされた方たちが「エンジニアとして爆速で成長していく」「早い段階でガッツリ稼げるようになる」ためには、「適切なタイミングで適切な環境に移動する」ことが必須となります。 さらにその「移動頻度」に関しては、皆さんの考えている「数年ごとに転職」程度では大抵の場合「少なすぎ」であり、特に最初の会社に関しては「1年程度で辞めることが望ましい」というのが私の見解になります。 以下、最初の会社を1年程度で辞めた方がよい理由

    エンジニアは最初の会社を1年程度で辞めた方がよい理由 - Qiita
    junpeso
    junpeso 2019/02/04
    ポエムタグお願いします