「grep」を含む日記 RSS

はてなキーワード: grepとは

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-07-16

エディタで使いたいんですが、rubyrails辞書ファイル定番ってありますか?

自分抽出しようと思って単純に def キーワードgrep しようと思ったら privateメソッドも含まれてきてしまうのでダメそうです。

2017-07-10

事務処理向けに高機能テキストエディタとはどんなものだろうか

https://anond.hatelabo.jp/20170706235735

勝手に具体的に考えてみる。

Excelなどの表計算に流し込むデータを加工する、表計算データメール文向けに加工する

CSV編集モードを持つエディタ

EmEditorなど最近は多いらしい。

grepsed、find、diff、uniq、count、sort相当の機能GUIから簡単に利用できるエディタ

マウス操作に優れたエディタ

マウス目的の部分をさっと選択できて、さっと切り貼りできる。EmacsViは1ストローク余計にかかって使いづらい。他のエディタなら大抵OK

定型作成支援

直子の代筆」みたいなもの

アウトラインプロセッサー、アイデアプロセッサー

長文執筆用。アイデア出し用。

執筆に集中するため全画面表示で余計なものを見えなくするエディタ

WriteMonkyなど

2017-06-30

死んだ

#!/bin/bash
typeset -r CurrentPATH=$(cd $(dirname $0); pwd)
typeset -r TIME=`date +%Y-%m-%d`

if [ $(echo ${CurrentPATH} | grep -e 'debug' ) ];then
    rm -rf ${CurrentPath}/
else
    mkdir ${CurrentPATH}/${TIME}

fi

2017-06-23

typescript-simple動作が何か妙だ

調査

環境は以下の通り

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.12.5
BuildVersion:	16F73

$ node --version
v8.1.2

$ npm --version
5.0.3

$ cat package.json
{
  "name": "strange-tss",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@types/lodash": "^4.14.66",
    "typescript": "^2.3.4",
    "typescript-simple": "^8.0.1"
  }
}

以下をトランスパイルする

import * as _ from 'lodash'; console.log(_)`

まずはtsc

$ cat test.ts
import * as _ from 'lodash'; console.log(_)

$ ./node_modules/.bin/tsc test.ts

$ cat test.js
"use strict";
exports.__esModule = true;
var _ = require("lodash");
console.log(_);

OK

$ cat compile_by_tss.js
require('typescript-simple')("import * as _ from 'lodash'; console.log(_)")

$ node compile_by_tss.js
/Users/zzzzz/Documents/strange-tss/node_modules/typescript-simple/index.js:168
                throw new Error(this.formatDiagnostics(allDiagnostics));
                ^

Error: L0: File '/Users/zzzzz/Documents/strange-tss/lodash.ts' is not a module.
L0: Cannot use imports, exports, or module augmentations when '--module' is 'none'.
    at TypeScriptSimple.toJavaScript (/Users/zzzzz/Documents/strange-tss/node_modules/typescript-simple/index.js:168:23)
    at TypeScriptSimple.compile (/Users/zzzzz/Documents/strange-tss/node_modules/typescript-simple/index.js:69:25)
    at strange-tss (/Users/zzzzz/Documents/strange-tss/node_modules/typescript-simple/index.js:13:27)
    at Object.<anonymous> (/Users/zzzzz/Documents/strange-tss/compile_by_tss.js:1:91)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)

う〜ん

$ ./node_modules/.bin/tsc --help | grep module
 -m KIND, --module KIND Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'.

2017-05-08

windows上で作成したファイルに対し、grepをかけようとしたが、改行コードが違っていたのでハマってしまった。

IFS=$' \t\r\n'をとして、\rも区切り文字列として認識させないと、grepで\rを探してしま検索結果がnullになってしまう。

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2017-01-17

サクラエディタgrep置換便利すぎる

これまで秀丸grep結果からいちいち手動で置換してたのに・・・

2017-01-11

サーバーの生ログを見る際にgrepでつい検索する文字列

2ch」…2chに晒されてないか

「t.co/」…ツイッターに晒されてないか

「.compute-1.amazonaws.com」…広告不正クリックがどれくらいあるか

「.*htm.*404」…直打ちで変な奴がきてないか

つい確認するよな?

2016-10-06

http://anond.hatelabo.jp/20161006161733

プログラマは、どこかの段階でオレオレ言語を作ると言われてるけど、

その前段階でオレオレgrepを作るんじゃないかと思ってる。

場合によっては黒歴史なんてこともあるんで、

あんまり真剣には見てやるな……。

まずはgnu grep/bsd grep互換で高速な実装を作ってほしいのだが

grepより高速・便利を謳うツールは沢山ある

https://github.com/ggreer/the_silver_searcher

https://github.com/monochromegane/the_platinum_searcher

http://blog.burntsushi.net/ripgrep/

が、一つ言いたいことがある

grepコマンド互換でない時点でどんな実装をしようと利便性は劣る

grepの利点はスタンダードを占めていることにある

スタンダードに取って代われないお前の実装は、悪いがgrep未満だ

2016-09-15

http://anond.hatelabo.jp/20160914215919

・当時から上等な図書館には書誌検索用の端末が用意されてた

・FINDっていうMS-DOSコマンド

 grepっていうUNIXコマンド

千里眼とかAltaVista

 → 最初期の千里眼はサーバ内部に持ったテキストファイルgrepしてたらしいな

文書内の語句検索

 WindowsならCTRL-Fを、MacならCommand-Fを押したら出るダイアログ

メールなどの検索

 1992年から僕らの業務連絡は電子メールが主になった。

 すぐにメール流量はいまと変わらないくらいになったので、

 今メール本文を検索するのと似たような感じには検索コマンドを駆使していたはず

2016-06-29

http://anond.hatelabo.jp/20160629152115

そういう、「捨てても良いコード」が沢山発生するからこそ記述が楽な言語活躍するんやで。でも、なんだかんだでgrep/egrepシェルコマンドで実行させるほうが最終的に記述量少なくなるけどな。

2016-03-31

http://anond.hatelabo.jp/20160331101136

うーん、さすがに今回の話はLinuxユーザースペースをWindowsに載せるって話だから

逆は難しいように思うけどね。

しろgrepとかawksedみたいなツールWindows移植やリコンパイルじゃなくて

そのままのバイナリが動くってのがキモだよね。

この辺のツール使いたくてMac選んだユーザーは端末の選択肢広がって良いと思う。

2015-08-18

http://anond.hatelabo.jp/20150818231612

間違ってるのが何か分かってないんだからそこは「cat -n | grep 肛問」じゃなくて「awk '!a[$0]++{print$0,NR}'」としようよ……。

あと「sed 's/../&\n/g'」でいいものperlでやらんでも。

(「grep -vn 肛門」というのもありか……)

http://anond.hatelabo.jp/20150818225813

ちょっ…いつの間に書き換えた><

perl -CS -pe's/(..)/\1\n/g' | cat -n | grep 肛問」した感じ137番目の肛門が肛問になってる。

2015-06-22

http://anond.hatelabo.jp/20150622110613

説明しよう!

「説明は必要ない、見ればわかる、わからないのは池沼」という文字列の中を「自明から」でgrepしてもヒットしないので、含まれないと判断するべきである

あいまい検索自分発言がヒットしてしまってはまずい局面を検知すると宇宙高能様は自動でこの完全一モードに移行する

なおこのプロセスは0.05秒で完了する

2015-06-07

おでんの集計

結局どうやるのが良かったんだろう。grepwcで頑張るには複雑すぎる気がした。

ツイートの取得のやり方は思いつかないんだけど、集計はmecabに渡した後Perlなりで名詞連想配列に放り込んでカウントダンプするのがよさそうかなと思った。

…量そんなないし手作業でやるのが一番だったかなぁ。。。

2015-05-02

著作権表示をどこに書くか

いくつかMITライセンスライブラリを使っているのだが、

著作権表示をどこに書けばいいのか分からなくてもやもやしてる。

どこかの記事ではAUTHORS.txtに書いてねと書かれてあった気がするが、

他人ソースコードgrepしてみてもそんなファイルは見当たらないし、

依存しているライブラリの作者に関する記述は見つからない。

…実は書かなくても良かったりするんだろうか?

2015-04-07

由来無いのか…

grepオプションにおける-A、-B、-Cの-Cみたいなものだろうか。

長いほうがおすすめされてるなら安心して使おうかな…。

2015-02-13

正規表現.*が便利すぎて鼻血でそう

ファイル検索ソフト全検索するときとか、

ソースファイル群を全grepするときとか。

これ一つ知ってるだけで検索めっちゃ捗る

ググるとき単語間に入れるスペースみたいな感じで、

キーワードの組み合わせで検索grepできるからマジヤバイ

正規表現バリバリに使いこなすことはできないけど、

これだけは絶対忘れないしちょくちょく使う。

逆にそれを考慮したファイル名にしたりプログラム書いたりとかね。

たぶんもっと正規表現使いこなせたら便利になるんだろうな。

でもそれはまた必要に応じて覚えればいいや。

2014-12-09

IMEユーザー辞書でどこでも捗らせる話

増田アドベントカレンダー2014の9日目の記事です)

最初作曲勉強して増田テーマ曲作ってメロディ記法?(というのがあるらしい?)で書いて載せること考えたけど、勉強間に合わなかった。

うんこ漏らせないし、小ネタとして、MS-IMEユーザー辞書でこういうことしてる的な話でも書こうと思います

内容

IME変換辞書定型句を入れとく

定型句は見つけたら登録してる感じ。この辺はありがち。

例えばこのようなものを登録する。

おせます お世話になっております
おせした お世話になりました。
かきけ 下記の件、
よろます 宜しくお願いします。
あざますありがとうございます
あざした ありがとうございました。
いじょ 以上となります

メールとか書くの速くなる…

同音異義語の変換時間を短縮する

同音異義語多い単語とか打ってると変換候補が多くて困惑するし、誤変換で確定して「あーっ!」とかなること多いけど、それぞれにオレオレ読みをでっち上げユーザー辞書に載せとくと少しだけ楽。辞書別に切っておく。

http://anond.hatelabo.jp/20140313130607

↑この辺みて割と最近思いついて使ってる話だけど、既にどこかで同じようなことやってる人もいるかも。

(例)

「へんこう」

へんむく 偏向
へんさら 変更
へんぴか 偏光

「げんこう」

はらこう 原稿
あらこう 現行
もとこう 元寇

などなど。「いじょう」「こうせい」とかいろいろあるので仕事が暇な時とかに登録していくといい感じ。

「たいしょう」

しんめと 対称
ぺあぞう 対象

忘れやすルールで略すとあまり意味がないので何かしら読み替えルールを作っとく良いのではないかと…。

キータイプ超人クラスになると、こんなことしなくてもIME学習機能を切って変換順序を丸暗記してるらしい。怖い。

IMEコードスニペット

以前やったお仕事IT部門規制ガチガチで、WindowsOfficeしか使えないVBA仕事があって全然捗らなかったけど、今思うとIME対応できたはず。

これもユーザー辞書単語登録しておく:

いf If - Then End If
ふぉr Dim i As Integer: For i = 0 To max Next i

試しに上のようなローマ字交じりの単語で登録して変換してみたけど、一応使えてる。

あとgrepdiffなくて苦労していたけどfindstrとfc代用できます

最近普通に機能エディターを使えるのでこういう悩みはない…。

あとMS-IME以外もOKな環境なら普通に予測変換やAZIKが使えるものを使うと楽。

…って感じですかね?

自分の書いたものとか生涯最高でも10ブクマぐらいなのでつまらなかったらごめんなさい。

あとメルリクリス増田

2014-10-12

http://anond.hatelabo.jp/20141012001248

tail -f access.log | grep purchase_hoge

確かにこれはありえねえwww

雑すぎる

雑文学だ

2014-10-11

ソーシャルゲーム開発者のもつ罪悪感

「先月は売り上げ○億円達成!、今月は△億円目指してがんばりましょう」なんて経営者から話を聞くたびに悲しい気分になる。

この人達は、分かっていない。何も分かっていないな。

現在日本ソーシャルゲームほとんどは、ガチャという凶悪ギャンブル要素が組み込まれており、売り上げの大部分を占めている。

偉そうな人が、「このゲームマネタイズ戦略は〜」とか言ったところで、結局ガチャである

ある日の俺。

おもむろにターミナルを起動して、ゲームサーバー接続

 tail -f access.log | grep purchase_hoge

入力

リアルタイム課金情報が画面に出力されるコマンドで、誰かが課金すると表示が1行増える。

「ああ、これが△億円目指してコツコツと積み立てられているのか」

ガチャ確率アップや割引なんかがあると、その表示速度も速く、ゲーム内の勢いを感じながらも、エラーが発生していないかをチェックする。

短い間隔で同じユーザー課金ログが表示されているな。と気づいたが、直前に新SRカードが追加されていたことを思い出して、ふと、ユーザーガチャ履歴データベースに問い合わせ。

「かなり引いてるな・・・

これだけやったなら、さすがに当たっていてほしい。と、今度はソート条件にカードIDを加えて検索

他のSRはあるものの、今回追加されたSRは出ていない様子。見事にゴミばかりである

そもそも、確率はいくつだ。と、確率を設定しているファイルを開く。

うわー(どん引き)

とは言えだ、期待値を上回る回数引いているんだよな。まさか・・・

(設定がきちんとゲームに反映されてないのか?)

(システムバグか?)

心配になって、今度はカードIDを使って検索

(いや、ちゃんと出てるな)

と、どうやら当たりを引いたユーザーはいるようで一安心

ついでに、今度は当たりを引いていたユーザー履歴検索

(まじか、一発で引いてる・・・)

これが運か。分かってる、運だよな。

その間にも、最初ユーザーガチャ履歴ゴミで埋まっていく。

もう、やめてくれー。

これ、引くに引けないパターンのやつや!(ガチャは引いてるけど)

もし当たりが出たとしても、課金額を知ったとき絶望以上の幸福は得られないだろう。

(もう、このユーザーは当たりが出るように設定しよう)

(いや、そんな仕組み入れてないぞ)

(じゃあ、先ほど引いたゴミカードを当たりに書き換えようかな)

(まずい、それじゃクレーム来たら大変なことになる)

(でも、より良いものになったのにクレームなんてしないはず)

(いやいや、そもそもデータを書き換えるなんてだめだろ)

など考えているうちに課金は止まった。当たりは出ていない。

彼(もしくは彼女)の気持ちを察すると、心が痛い。

もうこんな気持ちはたくさんだと、そっとターミナルを閉じる。

「先月は売り上げ○億円達成!、今月は△億円目指してがんばりましょう」なんて経営者から話を聞くたびに悲しい気分になる。

そのお金で食べる飯はうまいか?

俺はまずいよ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん