タグ

Qiitaに関するdecoy2004のブックマーク (129)

  • イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita

    はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ

    イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
  • 個人開発アプリのサーバーサイド環境を金と時間をかけずに用意する方法 - Qiita

    この記事はSansanアドベントカレンダー3日目です。 前提 個人でアプリを開発していても、やっぱりなんだかんだサーバーサイドが必要になる機会ってあると思います。ただ、注力したいのはやっぱりアプリ側の開発なのでできるだけサーバーサイドにはコストをかけたくない、そんなときどうすれば、、、みたいな話です。 基的には、 金をかけたくない 時間をかけたくない でもサーバーサイド用意したい という前提で雑にサーバーサイド環境を用意する場合の話です。 作ったアプリなど 最近は放置気味になっていますが、下記のようなアプリをこれまでにリリースしました。いずれも2人で開発した個人アプリで、アプリに注力しながらもそれなりに頑張ってサーバーサイド側も用意しました。瞬間最大風速では、1000リクエスト/秒くらいのアクセスがあっても特に負荷などの問題も起きず、一応正常に動作してました。 ヒミツのアルバム(写真管理

    個人開発アプリのサーバーサイド環境を金と時間をかけずに用意する方法 - Qiita
  • sedのパターンスペース・ホールドスペースの動作を図で学ぶ - Qiita

    概要 sedは、入力ストリームに対して様々なテキスト変換をおこなう、ストリームエディタです。 cut, grep, trといった基的なフィルタコマンドと比較して、柔軟なテキスト処理が可能です。 このsedの機能の1つとして、パターンスペース・ホールドスペースがあります。 高度なテキスト処理が可能になる反面、パターンスペース・ホールドスペースは、動作が理解し辛いという難点があります。 ですが、sedのパターンスペース・ホールドスペースの動作を丁寧に解説した記事は、私が探した限りでは見つかりませんでした。 そこで、sedを深く学ぶ方への助けとして、また私自身の復習として、sedのパターンスペース・ホールドスペースの動作を、記事としてまとめました。 記事では、sedのパターンスペース・ホールドスペースの動作を、図示して解説します。 実行環境 Arch Linux 4.8.8-2-ARCH G

    sedのパターンスペース・ホールドスペースの動作を図で学ぶ - Qiita
  • Qiita / esa.io / DocBase / GitHub Issues をアップローダの視点から徹底比較 - Qiita

    作業手順を説明したGIF画像を共有するためにURLがほしかったので、手軽なアップローダを探そうとも思ったのですが、こちらの記事を思い出して GitHub Issue で済ませることができました。 そこで、アップローダとして情報共有サービスのエディタ画面を利用する場合、どのサービスがよいのでしょうか。 気になったので、小さなデータを作成して確認してみました。 アップロードできる拡張子一覧1 Qiita esa.io DocBase GitHub Issue

    Qiita / esa.io / DocBase / GitHub Issues をアップローダの視点から徹底比較 - Qiita
  • Qiitaで技術系の記事を書く時に気をつけていること - Qiita

    技術系の文章を書く際、「ここを気をつけているだけである程度読みやすい文章となる」といったポイントをいくつかご紹介したいと思います。 はじめてQiitaに投稿する人や、そうではないにしても、文章の品質を気にされるかたの助けになればと思います。 文章外のコンテンツ編 サンプルコードはできるだけ豊富に用意しましょう。 Qiita記事は、いわばドキュメントなので、文章が重要であることは当然です。 しかし、わかりやすさで言えば、エンジニアではコマンドやソースコードのほうがわかりやすい場合も多々あります。 不要であればどちらかを読み飛ばすことも可能な上、片方ではしっくりこない人は情報を補完しやすいので、できるだけサンプルコードは豊富に用意しましょう。 サンプルコードが肥大化してきた場合、GitHubにおいてやるのも一つの手かもしれません。 日付は正しく記しておきましょう。 コメントより。 Qiitaの

    Qiitaで技術系の記事を書く時に気をつけていること - Qiita
  • あなたの知らない less の世界 - Qiita

    最近 prezto 入れたんですよ。prezto。そしたらいつものシェル世界が見違えるほど使いやすくなって身長も 3 メートルくらい伸びたんですが、それは余談でして、prezto 入れた後に less 使ってみたら余りの変わりっぷりに驚いたんです。 これを機に man page を読み直してみたら更に驚き。less ってこんなスゴイ物だったのか!みたいな。今回はそんな less の底力を紹介します。 環境変数 $LESS less には様々なオプションがあるのですが、これを予め環境変数 $LESS に設定しておくと、毎度 less ファイル名 と打つだけでそれが有効になります。更に、後述しますが、この設定は less 起動中にオン・オフして切り替えることが可能です。 # 最低限でもこれくらいは設定しておこう export LESS='-i -M -R' # 僕は後述の物を全部付けてます(-

    あなたの知らない less の世界 - Qiita
  • 責任(関心)を意識したアプリケーション設計 - Qiita

    プログラムが上手く組めるようになりたい プログラミングが上手くなりたいと考えたときに、個人的には『名付けを意識』するのと、『アプリケーション設計のときに責任を意識する』考え方を取り入れることをおすすめしております。 今回は『アプリケーション設計のときに責任を意識する』ことについて書いてみたいと思います。 基的には単一責任原則と、関心の分離のお話になります。 ※ タイトルに『関心』というワードがありますが、アスペクト指向プログラミングの話ではありません 単一責任原則とは まずは単一責任原則とは何かについてです。 よく単一責任原則の説明では「クラスを変更する理由は複数存在してはいけない」というニュアンスの言葉がよく使われます。 例えば、社員管理システムの実装を行いたい場合、一つのクラスに「社員登録」「出勤管理」「給与管理」などの機能を詰め込むと、『社員登録』の変更をする際にそのクラスが変更さ

    責任(関心)を意識したアプリケーション設計 - Qiita
  • Github projectsを使ってみた - Qiita

    Github projectsとは 2016/9/15にGithubが開催したannual Universe conferenceにて幾つかの新機能が発表された(既にリリースされている) 詳細 : A whole new GitHub Universe: announcing new tools, forums, and features なかでもアジャイル開発や、プロジェクトマネジメントという視点での目玉機能がカンバン式のタスク管理を可能にする機能『projects』である。 projects詳細 repositoryのリストにprojectが追加された projectsの中には自由にカラムを作り、カラムの中には既存のissueとPR、そしてnoteをcardとして入れることができる。 ドラッグ&ドロップでcardは移動可能 noteは Convert to issue でいつでもiss

    Github projectsを使ってみた - Qiita
  • 引き継いだソースコードをメンテナンスしやすくする。 - Qiita

    引き継いだコードは、メンテナンスしやすい状況になっていないことが多い。 「引き継いだソースコードを改変する前に」 http://qiita.com/nonbiri15/items/47e25c2d5fb46f3495df で引き継いだコードの可読性を少し改善したとする。 しかし、まだまだメンテナンスしやすいものにはなっていない。 そこで、メンテナンスしやすくするためのリファクタリングについて私の現状の理解を述べようと思う。 残っている課題 ・グローバル変数が残っている 対策: グローバル変数と、そのグローバル変数を書き換える関数群を、1つのモジュールファイルの中に押し込めよう。 そのとき、そのグローバル変数に無関係な関数や変数を、そのモジュールファイルに含めないようにする。 グローバル変数を参照する側、extern で参照できるようにしておく。 そのようにファイルを分割することで、グローバ

    引き継いだソースコードをメンテナンスしやすくする。 - Qiita
  • 若手エンジニアを不幸にしないための開発の「べからず」集 - Qiita

    若手エンジニアを不幸にしないための開発の「べからず」集を書いてみました。 「若手エンジニアを不幸にしないため」とは書いていますが、若手に限った内容ではありません。 いろんな開発の「べからず」のために不幸になるのは、とりわけ若手が多いということを意識したためだと思ったからです。 ・若手には、方針の決定権がない。 ・若手は、組織の中で道具のように扱われてしまう場合がある。 ・(今の)若手は、将来も働き続けるための力を付けるための組織内での教育が、(昔ほど)なされなくなってきている。 ・コスト意識が乏しいので必要性が乏しいことについてまで残業前提の仕事のスケジュールを組織がたてることが多い。(その分野の理論を知っていれば自明のことを実験で証明することを要求されるのは苦痛である。) 設計指針の「べからず」 何ができれば十分かを明確にしない 開発目標は、何ができれば十分なのかを明確にしないまま、追加

    若手エンジニアを不幸にしないための開発の「べからず」集 - Qiita
  • [Git] 古いリモートリポジトリから新しいリモートリポジトリへブランチ等も含めて引っ越し - Qiita

    $ git clone --mirror OLD_REPO_URL $ git remote add new NEW_REPO_URL $ git push --mirror new Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

    [Git] 古いリモートリポジトリから新しいリモートリポジトリへブランチ等も含めて引っ越し - Qiita
  • gitの管理を避けるためのあれやこれ - Qiita

    定期的にググってるのでメモ。 gitで管理されているファイル update-index --skip-worktree gitの操作の影響を受けない。gitの操作で変更されない。大抵こっちを使ってる。 # 登録 $ git update-index --skip-worktree <pathToFile> # 解除 $ git update-index --no-skip-worktree <pathToFile>

    gitの管理を避けるためのあれやこれ - Qiita
  • オープンソースプロジェクトのすゝめ - Qiita

    自前のブログからの転載。QiitaはJavascript使えないのがさみしい。 人は生まれながらにして貴賤の別なく、ただオープンソースプロジェクトを勤めて物事をよく知る者が貴人となるなり。 昔、偉い人がそんな感じのことを言っていたような。 私がGitHubで開発しているライブラリ、Pcap4J のスターの数がつい先日 200 に達したのを記念して、これまでどんな活動をしてきたか、この活動によって何を得たかなどについて書きたい。 願わくは、この記事に触発されてオープンソースプロジェクトを始める人のあらんことを。 Pcap4Jとは? Pcap4Jは、パケットキャプチャとパケット解析をするJavaのライブラリ。 ニッチ。 ただ最近になってビッグデータ解析技術が発達し、大量のパケットをリアルタイムで解析してシステムや運用にフィードバックするというのが現実的になってきたので、パケットキャプチャへの注

    オープンソースプロジェクトのすゝめ - Qiita
  • svn主流の職場にプルリク開発を導入するための口説き文句集 - Qiita

    概要 今更ですけどプルリク開発イイですよね。 自分がいるちょっと堅めの組織では、プルリク駆動が浸透するまでに1年半くらいかかりました。ただ、導入後のアンケートでははsvnを使いたいという人が皆無になるくらい、プルリク駆動開発には価値があると現場にわかってもらえましたので、導入時に効果的だった口説き文句をまとめてみました。 えらい人も説得しないといけないし、現場も説得しないといけないので、それぞれに向けたフレーズになっています。 なお中には、gitにもかかわらずtrunkという言葉を使っているケースがあります。これはgitのmasterブランチという言い方をするよりも、svn習熟者にtrunkという表現の方が刺さると考えられるため、あえてこういった表現をしています。 書かないこと gitの内部構造についての話や、使い方についての話など、これらの説明を補強するバックボーンについてはサラっとしか

    svn主流の職場にプルリク開発を導入するための口説き文句集 - Qiita
  • Emacs の window が横に分割されるのを防ぐ - Qiita

    問題点: window が横に分割されると見づらい Emacs で何か処理を実行して出力が別の window に表示されるとき、 split-window-sensibly が内部で実行されている。これは window に合わせて自動的に最適に window を分割してくれる関数。つまり横幅が長いなら垂直に分割して、縦が長いなら水平に分割する。 最近のPCは横長のディスプレイが多いので横に分割される事が多いが、行の長い出力を読む時は折り返されてしまうので私は 常に水平に分割して欲しい。 解決策: split-width-threshold に nil を設定する split-width-threshold のヘルプを見ると、 If this is nil, ‘split-window-sensibly’ is not allowed to split a window horizontal

    Emacs の window が横に分割されるのを防ぐ - Qiita
  • わかりやすいドキュメントを書くには 〜 全体像を把握できることが重要 - Qiita

    はじめに エンジニアなら誰でもたくさんのドキュメントを読むことになります。 その中にはわかりにくいドキュメントも少なからずあると思います。 自分はわかりにくいドキュメントは「全体像が掴みにくい」ことが多いと感じています。 そこで、ここではわかりやすいドキュメントを書くための方法を「全体像を把握できるようにする」という視点でまとめてみました。 また、最後に具体例としてQiita APIドキュメントでわかりにくい点の指摘と改善をしてみました。 ここで扱うドキュメントの種類 ここでは仕様書やリファレンスマニュアルといった類のドキュメントを想定しています。 Qiitaの投稿やブログの記事といったものでも共通する部分は多いのですが、これらには他にも重要な要素があると思うので、ここでは扱いません。 わかりにくいドキュメント=全体像が掴めないものが多い 先ず、わかりにくいドキュメントとはどんなものでしょ

    わかりやすいドキュメントを書くには 〜 全体像を把握できることが重要 - Qiita
  • 「Git補完をしらない」「git statusを1日100回は使う」そんなあなたに朗報【git-completionとgit-prompt】 - Qiita

    はじめに 「Git補完をしらない」「commitランチを間違える」「git statusを1日100回は使う」そんなあなたに朗報です。 bashの説明だけに絞っています。zsh? tcsh? 知らない子ですね。 いきなり完成形 # スクリプト読み込み source $HOME/.git-completion.bash source $HOME/.git-prompt.sh # プロンプトに各種情報を表示 GIT_PS1_SHOWDIRTYSTATE=1 GIT_PS1_SHOWUPSTREAM=1 GIT_PS1_SHOWUNTRACKEDFILES= GIT_PS1_SHOWSTASHSTATE=1 ############### ターミナルのコマンド受付状態の表示変更 # \u ユーザ名 # \h ホスト名 # \W カレントディレクトリ # \w カレントディレクトリのパス # \

    「Git補完をしらない」「git statusを1日100回は使う」そんなあなたに朗報【git-completionとgit-prompt】 - Qiita
  • たったひとつの技術書の選び方 - Qiita

    巻末の索引のページ数をみます。 入門書など沢山の同種類のを目の前にしてどれが良いなのかわからなく迷う時があります。(私は今まで優しい言葉で書かれていたり、イラストを多用していたり、カラーだったり、Amazonの評価が高かったりしたのを選んできました、しかしAmazonで発売されたばかりのには評価が無かったりします。) そこで巻末の索引ページを見ます。 200~300ページぐらいので索引が2、3ページしかなかったらハズレです。 二桁、十数ページの索引があるはアタリです。 全てに当てはまるものではないとは思いますが、索引のページ数が少ないは選ばないようにしたほうが無難です。

    たったひとつの技術書の選び方 - Qiita
    decoy2004
    decoy2004 2016/08/06
    『300ページぐらいの本で索引が2、3ページしかなかったらハズレです。』
  • 正規表現をテスト・可視化できるサイト - Qiita

    Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

    正規表現をテスト・可視化できるサイト - Qiita
  • sedコマンドの備忘録 - Qiita

    . # 任意の一文字 * # 直前の文字が任意の個数続く文字列(0個も含む) <space><space>* # 連続するSPACEを表す <tab> # TAB .* # 任意の文字列 sed -e "s/aaaa/bbbb/" # 置換 行で最初に出てきた'aaaa'を'bbbb'に置換 sed -e "s/aaaa/bbbb/g" # 入力の全行に渡って置換 (Global) sed -e "s/^aaaa/bbbb/" # 行頭(^)に'aaaa'のもの sed -e "s/aaaa\$/bbbb/" # 行末($)に'aaaa'のもの。$は\でescape sed -e "s/~/bbbb/" # 行頭に'bbbb'を追加 sed -e "s/\$/bbbb/" # 行末に'bbbb'を追加 sed -e "s/.*/abcd/" # すべての行を'abcd'に置換 sed -e

    sedコマンドの備忘録 - Qiita