vimが苦手でもOnivimカッコいいのでおすすめしたい - Qiita
この記事はVim その2 Advent Calendar 2018 22日めの記事です。 vimconf2018でonivimというGUIエディタを知り、なかなか好感度高いのでオススメしたい記事を書きます。 こんな人にオススメしたい vim使いたいけどなんかターミナルとかハードル高く感じる サーバーにログインしてvi使うからvim使いこなしたいけどwindowsだし環境を用意するのが面倒 新しいエディタを触ってみたい 人と違うエディタを使いたい かっこいいエディタを使いたい Onivimとは？ Oni is a new kind of editor, focused on maximizing productivity - combining modal editing with features you expect in modern editors. Oni is built wit
Scoopを使ったWindows環境構築のススメ - Super!! - Qiita
ネット上にあるWindowsの環境構築やソフト紹介の記事を見て、まず「クリック」という単語を見ないことはないと思います。 あまつさえエクスプローラー間でのドラッグアンドドロップに設定フォームへの入力をするだなんて……AnsibleやDockerがすでに浸透しきった昨今、果たしてこれ以上に異常かつ原始的なことが他にあるのだろうか? ……と、そんな反語表現をWindowsの環境設定のたびに考えているアナタのための記事になります。 なお内容があまりにも長くなりそうなので、以下の3記事に分割してお伝えする予定です。 総じて、マウスなしでの全環境構築の完遂を究極目標に、Scoopを主体として自動化できるものは自動化し楽をすることに主眼を置いた内容になります。 守章: Scoopの基礎、簡単なManifestの作成 ← 今回はこれ 破章: バージョン管理と自動アップデート 離章: Scoopを用いた環
VimでPerl（に限らないけど）を書くときにこれだけはやってほしい設定
" Disable AutoComplPop. let g:acp_enableAtStartup = 0 " Use neocomplcache. let g:neocomplcache_enable_at_startup = 1 " Use underbar completion. let g:neocomplcache_enable_underbar_completion = 1 " Set minimum syntax keyword length. let g:neocomplcache_min_syntax_length = 3 let g:neocomplcache_lock_buffer_name_pattern = '\*ku\*' " Use smartcase. let g:neocomplcache_enable_smart_case = 1 " Use camel
レビュー前に直して欲しい日本語の問題点８つ - Qiita
私はウンザリしています。 「○○対応」は曖昧なのでやめてください。「○○を修正した」の方が直接的です。 こんな指摘を新人が入ってくるたびにコードレビューやドキュメントレビューで繰り返しています。どうも、プログラマー（と言うか理系？）には独特の言語文化があり、みんな同じような分かりにくい表現をしてしまうようです。 「レビューを依頼する前にこれを読んどいて！」と言える記事なり本なりがあれば良かったのですが、良いものが見つけられなかった（ご存知なら教えてください）ので、とりあえずレビューでよく指摘する日本語の文章の問題点や変な表現ポイントを列挙しました。 なお「コメントは必要十分な量を書く」「チケット番号やWikiのURLを書く」といった、良く知られた・日本語に限定されない話題は省略しています。 （※コメント欄などの指摘を受け「補足」を追加） （※タイトル変更。「コードレビュー前に直して欲しい日
テスト仕様書 - Qiita
単体テスト 結合テスト システムテスト（機能テスト、負荷テスト、ボリュームテスト、セキュリティテスト、リグレッションテストetc) 受け入れテスト（シナリオテスト） 運用テスト 現場（案件）によっては、「開発エンジニア」 が一連のテストしたり、また 「QAエンジニア」 がテストしたりと異なります。 私の意見としては、 「開発エンジニア」 「QAエンジニア」 双方が確認すべきではないかと。 単体テストの実施は、開発者が担当します。 また、結合テスト（Integration Test）以降のテストはQAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、詳細仕様を把握しているPM、Pdmや開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあ
vimを使うとき十字キーで移動して、vimmerに殺されるその前に - Qiita
はじめに あなたがこの記事を読んでいるということは、私はすでにこの世にはいないのでしょう。 最期に、あなたに私の犯した罪を告白します。 そうです、vimでの移動に十字キーを使っていたのです。 この事実を知ったvim教の信者たちが血眼になって私を探しています。 きっと、私は見つかるでしょう。 そしてMacBookの十字キーを全て剥がされ、Logicoolの青軸キーボードで撲殺されるのです。 それほどまでに私の罪は重いということは重々承知しています。 もし、これを読んでいるあなたが私と同じ業を背負っているのであれば今すぐ逃げてください。vimmerはどこにでも潜んでいます。 今日笑顔で話していた同僚が明日にはキーボードで殴りかかってくるかもしれないのです。 だからせめて、私のささやかな抵抗をここに書き記します。 あなたが私と同じ道を辿らないことを願って・・・・ escは海よりも遠いということ
go-pear.pharにバックドアが仕込まれていた - Qiita
半年以内にgo-pear.pharを使った人は必ずチェックしましょう。 2019/01/19 PEAR公式Twitterアカウントからツイート。 このアカウント全然活動してない。 https://twitter.com/pear/status/1086634389465956352 A security breach has been found on the https://t.co/dwKlscDEFf webserver, with a tainted go-pear.phar discovered. The PEAR website itself has been disabled until a known clean site can be rebuilt. A more detailed announcement will be on the PEAR Blog once i
PHP7.4ではPEARがインストールされなくなる - Qiita
Disable PEAR 2019/02/01にDisable PEAR by defaultというプルリクが提出され、2019/02/11にマージされました。 commitからmerge日はどうすればわかるのだろう？ 内容 Installation of PEAR (including PECL) is no longer enabled by default. It can be explicitly enabled using --with-pear. This option is deprecated and may be removed in the future. PEAR(PECLを含む)は、デフォルトではインストールされなくなりました。 --with-pearで明示的に有効にしなければなりません。 このオプションは非推奨であり、将来削除される可能性があります。 これまではP
「コメントは書くな」 - 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
perltidy - Perlソースコード整形ツール - Qiita
About Perlのソースコードを統一したルールで整形してくれる。 チームでコーディングするとき、特に有用。 CPAN Perltidy How to install. $ cpanm Perl::Tidy which perltidyでInstall成功を確認 Setting $HOME/.perltidyrcに以下のように書く(Perl best practicesより) -l=78 # Max line width is 78 cols -i=4 # Indent level is 4 cols -ci=4 # Continuation indent is 4 cols #-st # Output to STDOUT -se # Errors to STDERR -vt=2 # Maximal vertical tightness -cti=0 # No extra indenta
なぜオブジェクト指向は難しいのか - Qiita
この記事の内容 この記事は「オブジェクト指向と10年戦ってわかったこと」という記事を書いた筆者が2年の時を経て「なぜオブジェクト指向は難しいのか」をテーマに、さらなるオブジェクト指向の理解を目的として、通常とは異なるアプローチでオブジェクト指向を解説したものです。 自然言語の限界 人は様々な物事に名前を付けて分類します。リンゴには「リンゴ」、車には「車」という名前を付けて分類、認識しています。そして車には「走る」という役割があり、それらの役割もまた名前をつけて分類し、認識しています。 しかし、このように自然言語を使って物事を識別しているのは人間であり、ゾウさんはリンゴを「リンゴ」という言葉に置き換えて識別したりしません。きっとゾウは「あ、これ前に食べたらめっちゃ美味かったやつやん！もっかい食ったろ！」といった感覚によってリンゴを識別している。つまり、当たり前ですが言葉とは人間が作り上げたも
結合（統合）テストにおける仕様書と管理のアンチパターン - Qiita
私が過去にやらかしたことを中心に、結合テストにおける「やってはいけないこと」をまとめてみました。 なるべく、専門書や資格試験ではお目にかかれない具体的な事項を挙げたつもりです。 本稿でいう「結合テスト」とは、単体モジュール同士を繋げて期待通りの動作を確認する作業（＝単体テストの次のフェーズ）のことです。 会社によっては「統合テスト」と呼びます。 本稿の内容は執筆者個人の経験に基づく完全に個人的な意見であり、所属企業における立場、戦略、意見を代表するものではありません。 仕様書のアンチパターン 事前に準備しておくべきデータがわからない 例えば、テストを進めている途中で仕様に突然「現在庫が無い、かつ、翌日以降に入荷予定がある商品を選択する」という条件が登場し、該当するデータがないとテストケースを最初からやり直しになるハメになるとか… 隅々までくまなく読まないと準備すべきデータが読み取れないよう
CentOS7でtelnetを有効にする - Qiita
はじめに telnetは汎用的な双方向通信である。サーバーとクライアントの間でテキストベースの通信を行うことができる。非常に単純な通信であり暗号化もされておらず、セキュリティ上問題があるため現在は非推奨となり、sshに置き換えられている。実際、macOSXにおいても、High Sierraからtelnetやftpはなくなり、使用する場合はhomebrewやmacportsでinetutilsをインストールしなければならない。しかし、製造業など現場によってはtelnetでないといけないようなケースもままあり、完全には駆逐されきっていないのが実際である。 今回、現場で利用しているtelnetサーバに対し、特定の条件が揃うとうまく接続できないケースがあった。今回、そのケースを再現および確認するためのメモを残す。 telnetサーバを立てるまで 環境は、CentOS7系とする。 # telnetク
CentOS 標準搭載の Perl に負けないで強く生きる - Qiita
この記事では、OS 標準の Perl で動く CLI ツールを作ってる際に CentOS でハマる点について説明しています。 TL;DR Linux / Mac OS X の多くの環境では標準で Perl 5 がインストールされいる しかし CentOS 標準の Perl 5 の コアモジュールは欠けている OS 標準の Perl に依存した CLI ツールを作る時は注意が必要 なぜ標準インストールの Perl を使う必要があるのか 現在使われている Linux の多くや Mac OS X には、標準で Perl 5 がインストールされています。 しかし、Perl でウェブサービスを開発する際には、それら標準でインストールされている Perl ではなく、独自でインストールやビルドした Perl を使うことになるでしょう。 しかし、日常的に Perl を使っている人向けではない CLI ツー
今日のクソコード - Qiita
仕様書も何もないので直接プログラムをみて、ある機能の修正しなければいけない そこで遭遇した今日のクソコード $this->searchForm['search']['month'] は「201603」などの検索月がはいるのだが。。。 $target_month = $this->searchForm['search']['month']; $tt = explode(',', date('t,j,Y-m-,t,Y-m-,w', strtotime("${target_month}01"))); ～～～～ if($target_month != date('Ym')){ //過去日の場合 $tt[1] = $tt[0]; unset($tt[2]); }else{ $tt[1] = date('j') - 1; $tt[2] .= $tt[1]; } $rday = 0; if($tt[2]
コマンドラインコンパイラ csc.exe で C# コードをコンパイルする - Qiita
はじめに Windows には C# のコンパイラ（csc.exe）が既定で含まれており、Visual Sutdio をインストールしなくても C# コードをコンパイルすることができるということで、実際に試してみました。動作確認は以下の環境で行いました。OS をインストールしただけの素の状態です。 Windows 10 Professional x64 Creators Update（英語版） ソースコード 素の状態でエディタもインストールしていないので、メモ帳でコードを書いていきます。デスクトップに HelloWorld.cs というファイルを作成して、以下のコードを入力します。Hello World と表示するだけの何の変哲もないコンソールアプリケーションです。
VirtualBox 6.0.6にアップデートするとvagrant upでフォルダが共有されなくなった。 - Qiita
The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! setup Stdout from the command: Stderr from the command: bash: line 4: setup: command not found 一先ず、事象が解消したので共有したいと思います。 更新したバージョン VirtualBox：6.0.6 Vagrant：2.2.4 結論として、VirtualBoxのバージョンが問題でした。 VirtualBoxのバージョンを6.0.4にダウングレードすることで改善しました。 参考：https://github.com/dotless-de/vagrant-vbguest/
Javaのサポートについてのまとめ2018 - Qiita
Javaのサポートについてのまとめ Javaのライセンスやサポート状況について混乱が発生しているように思います。Javaのサポートを各団体がどのように行なっているかをまとめてみます。 知っておいてほしいのは、Javaの実装やサポートはOracle JDKかOpenJDKの二択、ではなくAdoptOpenJDKやAzul Zulu、Corretteなど多くの選択肢があるということです。 ここでサポートはバグやセキュリティに対応したパッチがリリースされることを表しています。 Javaのリリースサイクル これまで、Javaは3年ごとを目標に結局5年くらいかけて次のバージョンを出したりしていましたが、それでJavaはなかなかバージョンアップしなくて古いと言われていました。それが2017年9月、今後は6ヶ月ごとにフィーチャーリリースを行うというリリースモデルに変更されました。Java9が2017年9
Ansible get_url モジュールで、冪等性を考えてみる - Qiita
Ansibleのモジュールを使っていて、get_urlモジュールの冪等性が気になったので動作を確認した。 何が問題か get_urlモジュールは、wgetやcurlのように、外部からファイルをダウンロードしてくる訳だけど、ダウンロードに失敗してファイルが途中で切れていたりすると、その後のtar展開などで困る。 しかし、get_urlのデフォルト動作では、Playbookを再実行しても、壊れたファイルを見て「あ、もうダウンロード終わってるじゃん」となってしまい、ファイルを再取得してくれない。 おまけをつけると、ダウンロードしたファイルが更新された時だけ、その先のビルド処理を流したい。 解決方法 まず、get_url に sha256sum オプションを渡してあげる。 さらに force=yes を渡してあげる。 すると、ファイルが既にあったら、最初にsha256sumチェックサムを見てくれて
若手エンジニアを不幸にしないための開発の「べからず」集 テスト編 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集が 長くなりすぎたので、テストに関する部分を別項目として独立させました。 まだ、随時、修正です。 以下の記事と内容がかぶっている部分があります。 もぐらたたき開発を卒業しよう もぐらたたき開発を卒業しよう 対策編 テストの「べからず」 [Test First]を実行しない。 そんなわけで、コーディングの項目よりも先にもってきて見ました。テスト駆動開発TDDをぜひ試してみてください。『テスト駆動開発による組み込みプログラミング――C言語とオブジェクト指向で学ぶアジャイルな設計』 最初にこの本を紹介したように、テスト駆動開発を強く推奨します（まだ私はテスト駆動開発を使いこなせていませんが）。テスト可能な枠組みをソフトウェアの設計に入れることが必要なので、ソフトウェアの設計に強く関わっている手法だと理解しています。 「テスト軽視｣アンチパター
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
