サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
やる気の出し方
ameblo.jp/itboy
ロボ太@kaityo256 分かる人にだけ共感してほしい。 https://t.co/A6x0s2TcGX 2017年09月11日 19:50 これはよくわかるし実際そうなっちゃうことも多い。 ただ、実際そうなってしまう理由を考えてみると状況や環境の制約などによるものも多いと思ったり。 細切れの時間の中でできること 1つは、本来やらないといけない優先度の高いタスクってある程度大きな時間の枠が必要なものが多かったりするわけなんですけど、それを押し込める時間が1日の中にあまりないという点。 会社でのスケジュールを見ていると、打ち合わせが飛び飛びで入っているし、決められた時間で作業しないといけないタスクもあるし、時間が空いたと思ったら「今いいですか?」とか声かけられるし、やらないといけないタスクを集中して実行する時間枠が取れなかったりするわけです。 エンジニア視点で言うと、コードを書くときには集
グリーCTO藤本氏が明かす、エンジニアリングの観点をマネジメントに生かす具体的な方法 / @IT マネジメントやってと言ったら「ええっ」って反応が返ってくるというのは確かによく見る風景で、普段から技術的なことばかりしているとマネジメントというのが畑違いのように感じているエンジニアは多い気がします。 マネジメントという領域がシステム部門ではなく人事や総務、企画や戦略系などの他部門の仕事のように感じてしまうのかもしれません。 ただ、一方でマネジメントしてくれる人はエンジニア畑の人がいいと思っている人も多いのではないでしょうか。 つまりは、自分はやりたくないけど同じエンジニア出身の誰かに管理されたいと思ったりしていてそのジレンマがそこにはあるように思えます。 エンジニアとしてのこだわりが伝えられる相手 何故、エンジニア畑の人にマネジメントされたいかというと1つは話が通じる相手であってほしいという
これはシステム要件における顧客が求めているものと実際を揶揄した図ですが、現実に要件が求めているとおりに実装されることはまれだったりもします。 要件定義書に書かれたシステムイメージは非常にシンプルでも、仕様を詰めていく段階でどんどんと盛り込まれていく機能。 作り上げられたものは当初の要件からとはかけ離れたものになっていた、なんてものはシステム開発においてよくある話で、契約のもめごとや開発遅延の話は置いといて、なんでまたこんなに仕様が複雑化していくのでしょうか。 一つは現行業務への固執ではないでしょうか。 現行業務における課題を解決すための手段としてシステム開発を行うものの、その業務があるべき姿かどうかについてはあまり議論されないケースがあったりします。 つまり、現行業務に合わせてシステムが作り上げられるので、業務に内在する課題もそのままシステム仕様として実装されることになります。 現行業務を
むかしむかし、組織がそしてシステムが小さな頃は開発や保守、運用という区切りは存在せず、みんなが全てを担当し、一丸となって運営を行っていました。 しかし、システムが複雑になるにつれ、組織も大きくなり、何時しかそれらの作業は1人1人のキャパでは回しきれなくなっていきました。 そこで困った組織長はチームを二分し、開発(・保守)と運用という役割に分けることにします。 チームの役割をはっきりさせることによって組織運営を円滑にするための措置でしたが、それによってチーム同士の戦いが始まることになりました。 今ではシステム運営のイロハが世に出回っていますから、こんなストリーのように最初から非効率な状態で開始されるということはないかもしれませんが、それでも組織自体が小さかったり、要員が少ないという場合はどうしてもこのように非効率な状態から開始せざるを得ないというのはあるでしょう。 サービスを作り上げた当初、
composerを使って管理するパッケージの中で、開発環境では必要だが本番では必要ないといったパッケージもあったりします。 例えば、テストツールのPHPUnitは開発環境では必要だけど本番ではいらないといった具合です。 こういった場合でも、composer.jsonをうまく書いてあげれば環境を分離して不要なパッケージを本番環境に導入せずに済んだりします。 前回の[Composer] composer.jsonを読み解く にて、composerでインストールしたいパッケージはrequireキーの中にJSONの配列形式で記述すると書きましたが、require-devという項目も存在します。 文字通り、開発環境で必要なパッケージを定義するもので、デフォルトではこのrequire-devに指定したパッケージもインストール、更新の対象となります。 { "require": { "pear/pear_
コントローラーファイルにごりごりとビジネスロジックを書いていくようなやり方もありますが、コントローラー間の共通処理など別ファイルにロジックを分離したいということはよくあることです。 ってことで、Laravelでライブラリを定義する方法のまとめです。 ここでは、Laravel4.2をベースに書いています。 基本的にLaravelはファイルやディレクトリの構成の制約をうけません。 どこに何のファイルを置いているのかを定義しておけば素直に読み込んでくれます。 ということで、まずはライブラリ用のディレクトリ(lib)を今回の例ではlaravel/app以下に作成するとします。 $ cd /path/to/laravel/app $ mkdir lib この下にライブラリファイルを作っていくわけですが、このディレクトリへのパスの通し方は幾つか方法があります。 まずは、composerを使う方法。 c
前回のエントリ内で書いたcomposer.jsonは下記の内容でした。 { "require": { "squizlabs/php_codesniffer": "dev-master", "pear/pear_exception": "1.0.*@dev", "pear/log": "dev-master" } } この中で、requireキーにはComposerで管理する対象パッケージとバージョンを「:」で区切り(というかJSONの配列フォーマット)で記述します。 Packagistを見ながらインストールする場合、requireキーの書き方は記載があるので参照しながら書いていくのがよいと思います。 特定のバージョンをインストールしたい場合は、バージョン欄に番号やブランチ名などを指定します。 バージョンの番号はワイルドカードやレンジで指定することもできます。 「1.0.*」とした場合、1.
composerには、composerでインストールしたパッケージを呼び出すためのオートローダー機能を備えています。 これは何もcomposerでだけ使えるというわけではなく、自分たちで作成したライブラリなんかもこのオートローダーを使って自動で呼び出せたりす るので便利です。 もちろん、クラスファイルのオートローダーを実装する で書いたように、自前のオートロー ダーを作成することもできますが、ライブラリのパスが固定になったりPSRなどのコーディング規約に沿ったファイルパスを使いたいといった場合 に作りこむのが手間だったりもします(そういうサンプルは公開されてたりもしますけど)。 ってことで、composerのオートローダーを使って自前のライブラリを呼び出すための手順です。 マニュアル に書いているように、オートロードする には幾つかの方法が存在します。 まずは、PSR-0に準拠したライブラ
クライアントからサーバーにファイル転送をする際に、FTPやSCPのコマンドが利用できなかったり、ネットワークやポートの制限がかかっていて転送できないというような場合があります。 その他にも、踏み台サーバーを経由してアクセスしないといけないなど、直接ファイル転送するのが著しく面倒だったりする環境もあったりします。 そういったときに、lrzszパッケージを利用すればターミナルエミュレータを通してファイルを転送することが出来ます。 これは、TeraTermなどクライアントのターミナル環境を通してつないでいるまさにそのサーバーにファイルを転送したり、そこにあるファイルを受信したりすることができます。 まず最初に、lrzszパッケージがサーバー上に存在しない場合は、yumコマンドなどを通してインストールしておきましょう。 # yum install lrzsz - snip - Installed:
CakePHPを利用する場合、そのサーバーのDocument Rootにインストールしてしまうのが一番手っ取り早いのですが、場合によってはDocument Rootを他のツールやコンテンツで利用したいために、他のパスで動作させたいということがあったりします。 ということで、元々Document Rootで動かしていたCakePHPを別のパスで動くようにお引越しした際の備忘録です。 環境は、CakePHP2.3.7+Apache2.2.15で動かしています。 まず、CakePHPは下記のパスにインストールされているとします。 /var/www/cakephp DocumentRootでCakePHPを動かしていた頃のApacheの設定ファイル(httpd.conf)のVirtualHostは下記のようにしていました。 <VirtualHost *:80> ServerAdmin webmas
Linux上のユーザーのリソースの使用状況であったり、運用のポリシーを下に様々な制限を加えたいという場合があります。 例えば、利用するディスクスペースや生成するプロセス数の制限であったり、ログイン数を限定するという具合です。 ということで、その制限方法をまとめていきたいと思いますが、環境としてはRedHat5.9をベースに書いています。 ユーザーのリソース制限の設定はこのファイルに内容を書いていきます。 例えば、あるユーザーが生成するプロセス数を限定したいという場合 foo soft nproc 20 foo hard nproc 100 のように書いておきます。 書式としては ユーザー名(または@グループ名または*で全ユーザー) soft | hard 識別子 設定値 となります。 nprocが最大プロセス数を定義するための識別子となるので、今回の場合はfooユーザーに対して20のプロセ
CakePHPのとあるアクションにアクセスしたら別ページに転送したくって下記のようなコードを書いてたんです。 public function index() { $location = "http://example.com/app/index"; header("HTTP/1.1 302 Found"); header("Location: $location"); } で、何故かうまくいかなかったんで、Viewファイルも用意してそちらでもHTMLで転送するように書いていたんです。 <html> <head> <meta http-equiv="refresh" content="0;URL=http://example.com/app/index"> </head> <body></body> </html> これでうまく転送されたんでほっといたんですが、よくよく見るとHTTPステータ
最近、採用の広告などでフルスタックエンジニアという言葉を見かけます。 あんまりよくわかっては無いんですが、ネットワークやサーバー、OSなどのインフラ関連からプログラミングやHTMLなど幅広いレイヤーの知識を持っている人を募集しているようです。 個人的にはそんな人がチームに入ってくれるんなら願ったりかなったりだとは思うのですが、技術が複雑さを増していく中でそんなレイヤー1から7とかまでをちゃんとわかっている人なんてそうそういないだろうとかも思ったりするわけです。 最近は高度なライブラリが揃っていたりクラウド系のサービスによってそんなに知識が無くても新しい仕組みを作ったりすることはできたりします。 ただ、それを支えるエンジニアという職業から見れば、やっぱり一つ一つに対してきちんとしたスキルを持ってないと通用しないわけで、じゃあそれが幅広いスキルを横断的に身につけられるかというと技術の多様化によ
404(Not Found)や500(Internal Server Error)などページが無かったり内部エラーが発生した場合や、処理の過程で発生した例外エラーなど、何か問題があったときに表示するエラーページをカスタマイズしたいという要件はよくあります。 CakePHPでは、そういったカスタムエラーページを所定の手続きにそって行えば簡単に作ることができます。 CakePHPではデフォルトでHTTPステータスコードが404や500が発生した場合に出力するテンプレートを持っています。 /path/to/cakephp/app/View/Errors この中にあるerror400.ctpがHTTPステータスコード404が発生した場合のエラーページ、error500.ctpが500用のエラーページです。 これを好きにカスタマイズすることでオリジナルのエラーページを作ることができます。 エラーペー
IDやパスワードを一元管理するために、Active Directoryと連携したいというケースがあったりしますが、ADへ認証やパスワード変更などをPHPから行うためのメモです。 LDAPを通して簡単に認証やパスワードなどの属性値変更が行えます。 PHPは5.3系を使っています。 Windows側はWindows2008およびWindows2012で動作確認しています。 これは特に難しいことなく、PHPのldap_bind を使えば認証が行えます。 <?php $host = "ldaps://192.168.0.100"; $ldapConn = ldap_connect($host); // userprincipalnameを指定 $userId = "username@testdomain.test"; $userPass = "HogeHoge12"; ldap_set_optio
前回「Apache Solrのデモ環境を作ってみる 」にてApache Solrへのデータの取り込みをしてみましたが、Apache Solrはマルチコアに対応しており、複数のデータベースを作ることが可能です。 例えば、本番用とテスト用のコアを作って別々に管理したり、検索対象のアイテムによってコアを分けて検索結果を別々にするということが可能になります。 コアの追加方法は管理サイトから簡単に可能そうなのですが、この機能だけではどうもうまく動作してくれません。 下図のように「Core Admin」メニューの「Add Core」から追加しようとすると Error CREATEing SolrCore 'new_core': Unable to create core: new_core とエラーがでて作成できません。 そもそもの仕様ではありそうなのですが、一部の操作をサーバー上で手動で行う必要があ
サーバーの台数が増えてくると個々のサーバーへのパッチの適用作業というのは結構手間になってきたりもします。 しかも、パッチを適用することでそれらのパッケージを利用したプログラムとかに影響が出たりして、十分に検証期間を取った上で本番環境に適用したいというニーズが出てきたりもします。 というわけで、単純なyum関連のコマンド(yum、yumdownloader、createrepo)を利用してパッチの適用作業を自動化する方法について書いてみたいと思います。 なお、環境はRedHat5系をベースにして書いています。 まず、システム構成のイメージとしては下記のようになります。 社内用のリポジトリ兼検証用サーバーは通常通り外部のリポジトリから最新パッチを適用していき、その影響調査および本番サーバーに配布するためのリポジトリサーバーという役割を担います。 詳しくは後述しますが、もう少し本番適用までを慎重
Linux上でファイルのバックアップしようと思って一番シンプルにするとなるとcpコマンドを使うことになるかと思います。 まぁ、単純に $ cp foo bar みたいなことをするんですが、GNUオプションをみているとバックアップする用途なら結構便利そうなオプションが幾つかあります。 良くありがちなのが末尾に番号をつけていくというものです。 $ cp foo foo.1 みたいな。 ただ、番号(バージョン)をきちんと管理したいなら手動でやるとミスるので下記の--backupオプションが便利かもしれません。 $ cp --backup=numbered -f foo foo $ ls foo foo.~1~ $ cp --backup=numbered -f foo foo $ ls foo foo.~1~ foo.~2~ 2回実行すると番号がインクリメントされていきます。 cpはコピー元とコ
「Apache Solrのschema.xmlを読み解く 」にて少し書いたことですが、Apache Solrの設定ファイル(schema.xml)には様々なフィルタが設定可能で、それによって検索結果が大きく異なってきます。 フィルタの数は多数あって、利用用途やトークナイザーによって変わってきますのでここで書いているのは一部なんですが、こんな検索にヒットさせたいといった場合にフィルタの使い方次第で検索精度を高められたりするので、どういったフィルタがあるのか知っておけば用途に応じて使い分けられて便利です。 ここではApache Solrはバージョン4.6.1を使ってフィルタの検証をしています。 フィルタ(filter)要素はschema.xmlファイルのfieldType要素内に定義していきますが、charFilterという要素もあったりして少し混同したりします。 charFilterは、文章
コマンドライン処理をPHPで作りたい場合、わざわざCakePHPでバッチプログラムを作らなくても、っていうのはあるかもしれませんがWebをCakePHPで作っているのであれば、そこで作ったコンポーネントやモデルなどを再利用できるため何かと便利だったりします。 CakePHPのバッチプログラムは、下記のパスに保存します。 /path/to/cakephp/app/Console/Command バッチプログラム名は、指定したいプログラム名に「Shell.php」をつけて定義します。 プログラム名が長い場合、キャメルケースを使って定義している方がよいでしょう(理由は後述)。 そして、バッチプログラム本体は、同ディレクトリ内に存在するAppShellクラスのサブクラスとして定義します。 <?php class HogeDataImportShell extends AppShell { /**
Linux環境で、共有ユーザーを使っている場合に過去のコマンドの実行履歴を見てみようとしても誰が発行したものかわからなかったりして、何かサーバーに問題があったりした際にどのような作業をしたのかがわからずに困ったりすることがあります。 まぁ、共有でユーザー使うなよって話はありますが、そういった場合でも接続元のIPアドレスごとにhistoryコマンドの実行ログファイルを分けて保存することでユーザーごとのコマンド実行ログを残せたりします。 historyコマンドは、bash環境では通常は.bash_historyに保存されていきますが、これは環境変数で設定を変えることが出来ます。 以下のように、接続元のIPアドレスをベースにhisotryファイルを作るように.bash_profileに記述しておきます。 export RIPADDR=`who am i | cut -d '(' -f 2 | s
Apache Solrにはクエリ内に使う際に注意が必要な特殊文字が幾つかあります。 Apache Lucene - Query Parser Syntax 上記マニュアルによれば、下記の文字列が特殊文字に該当するようです。 + - && || ! ( ) { } [ ] ^ " ~ * ? : \ 管理ツール上のQuery機能を使って特殊文字をそのまま入れて検索してみてもSolrがエラーを返してきます。 org.apache.solr.search.SyntaxError: Cannot parse '&&': Encountered " <AND> "&& "" at line 1, column 0. ということで、この辺の特殊文字の意味とこれらをクエリに使いたい場合の回避方法のまとめです。 ・ 丸括弧() Solrで丸括弧(小括弧)の文字はグルーピングを意味します。 例えば、「Apa
昨年末にPHPのセッションアダプションの話題が出ていて、そういった記事を読んでいるうちに自分の環境を見直してみると全然理解していない部分があったんだなということで、その辺をまとめてみたいと思います。 PHPのセッションアダプション脆弱性は修正して当然の脆弱性 @ yohgaki's blog セッションアダプションの問題の根幹はこの部分にあって、セッションIDはプログラム側で作られるものだと思い込んでたものが、Cookieを通して任意のセッションIDを送り込まれてそのまま利用されてしまうという問題です。 確認(攻撃)方法はいたって簡単で、PHPのセッション管理をCookieベースで行っている場合に、そのCookie内のセッション変数(php.iniのsession.name)に任意の文字列を入れて送り込めば、そのセッションIDで利用が開始されてしまいます。 例えば、よくあるログイン管理のプ
SSHには元々、rootユーザーのログインを制限する(※)ことが可能ですが、rootユーザー以外でも特定のユーザーのログインを制限する事が可能です。 ※ sshd_config内で「PermitRootLogin yes」と設定 設定方法は、sshdの設定ファイルである「sshd_config」を編集します。 下記のように、「AllowUsers」の後に、「ログイン可能」なユーザーを列挙していきます。 AllowUsers itboy ※ 複数ある場合はスペースで区切っていきます。 編集後は、SSHDのプロセスを再起動します。 これで、「AllowUsers」で指定したユーザー以外、ログインする事が出来なくなります。 IPアドレスと組み合わせてもう少し複雑な制限をかけることも出来ます。 AllowUsers itboy@192.168.0.100 上記の場合、「192.168.0.100」
確かに身も蓋も無い話ではあるが。 「できない人」にいくら教えても「できる人」にならないのか @ ITpro 突き詰めれば「できる人」というのは「やる人(やる気のある人)」であったりもします。 ただ、「やる人」であったとしても「できる人」であるとは限りません。 まぁ、仕事においては論外という扱いなのかもしれませんが、「できる人」を育てるよりも「やる人」を育てるという方がずっと厄介だったりもします。 やる気があるのに空回りするとか失敗ばかりするという人は周りにもいることでしょう。 しかし、本人のやる気がある分、こちらも教える気にもなりますし、どこかしら失敗ばかり繰り返すその姿に(たまにイラっとしながらも)どこか愛嬌を感じたりもします。 一方でやらない人は、自分の領域を作り何を言ってもそれ以上のことはせず、それ以下であることがしばしば目立ちます。 この記事にあるできる人の長年のカンというやつも、
Apache Solrをデフォルトのままで利用しようとすると、管理サイトへのアクセスや検索や情報の更新もどこからでもできたりします。 これは、セキュリティ的にまずいので、Solrへのアクセスを制御する方法をまとめてみます。 なお、環境はRedHat5.9にApache Solr4.2を利用した環境です。 Solrは付属のJettyで動かしているので、その他の環境で動かしている場合は設定が異なるかと思います。 管理サイトをつぶしてしまってかまわないのであれば、JettyがListenするIPアドレスを下記のようにローカルホストからのみに変更するのが手っ取り早い方法かもしれません。 <New class="org.eclipse.jetty.server.bio.SocketConnector"> <Set name="host"><SystemProperty name="jetty.hos
先日電車に乗っていたら、後ろの方で若い子達が「LINE送って既読になってんのに無視された」って騒いでいました。 ひどいとかぎゃーぎゃー騒いでたんですが、まぁ確かに自分もいい気はしないけど返事を求めてない場合もあるし、求めてたとしても相手の都合もあるだろうし、返事しないならしないで勝手にこっちで進めちまえばいいやーみたいな感覚だったりもするんですが、子供の頃からコミュニケーション手段としてネットが当たり前に使われている世代にとっては、「届いているはずなのに返事しない」って言うのはリアルに会っていて挨拶したのに無視されているような感覚を持っているのかなとも思ったりしました。 情報機器の発達とともに当たり前につながる手段を誰しもが手に入れている状況下では、相手に届けたメッセージが届いているとわかるとともに誰しもがどんな場所でも返答できる環境を作り出しています。 これは利便性を高めるとともにSNS
若いエンジニアに仕事を頼むと、時にやりすぎなところがあったりして悩むときがあったりします。 それはあらぬ方向に突っ走られるというよりは、頼んだ以上のことを実装したりするといったシーンです。 それって別にいいことなんじゃないの?って思われるときもあるのですが、プロジェクトを管理しているとそこに時間を割くのではなく他に手を回したい、でも作ったものはそれはそれで素敵な機能なんで叱るに叱れないといった状況に悩んだりするわけです。 特に経験の浅いエンジニアは作る楽しさを覚えて間もなかったりもしますから、予想以上に工数かかっているなって確認してみると想像で突っ走ったりしてとんでもないものを作ろうとしていることはしばしばあります。 ちゃんと仕様を伝えていないこちらも悪いところがあるのですが、あまり細かく管理していくのもエンジニア自身の成長の妨げになりますし、自分もそうやって自由に作ることでスキルを磨いて
前回の「Apache Solrのデモ環境を作ってみる 」にて動く環境が作れたので、今回はもう少し突っ込んだApache Solrの設定ファイル周りについて書いていきたいと思います。 Apache Solrの環境設定で触るファイルは大きく2つあります。 1つは、Solrの動作自体を定義するsolrconfig.xmlファイル。 そしてもう1つは、Solrに取り込むデータのスキーマ情報を定義するschema.xmlファイルです。 何れも、 /path/to/solr/example/solr/collection1/conf に、存在します。 先のエントリでも書きましたがcollection1はSolrのコアディレクトリとなるため、コアを追加したらそのコアごとに設定ファイルが存在します。 順に説明したいところではありますが、solrconfig.xmlファイル(Solrの管理メニューのConf
次のページ
このページを最初にブックマークしてみませんか?
『A Day In The Boy's Life』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く