タグ

関連タグで絞り込む (249)

タグの絞り込みを解除

*programmingに関するelwoodbluesのブックマーク (1,140)

  • 取引先がエンジニアの服装にクレーム 「あんなだらしない格好のスタッフを寄こして…」 : SIerブログ

    1 :@@@ハリケーン@@@φ ★ 2013/05/18(土) 20:58:51.09 ID:??? これから夏にかけて、職場ではさまざまな形で「軽装」が進むと予想される。昨今は 節電を兼ねて、室温が摂氏28度でも快適に過ごせる「スーパークールビズ」を推進しようと いう動きもある。 社内にいる分には、どんな格好でも問題ないといえばないが、社外の人と合う場合には、 そうはいかない。ある会社では、商談に同席したエンジニアの服装を取引先が問題視し、 クレームが入ってしまった。総務の担当者は、このまま放置しておいてよいものかと頭を 悩ませている。 ■社員は「でも自由って言ってたじゃん」 ――アプリ開発会社の総務です。最近、仕事の引き合いが多く、売上も従業員も急増して います。それに伴い、取引先からのクレームも色々と目立ってきました。 元々創業者の仲間うちで始めた会社なので、最低限のルールしかなく、

  • PC時代のおわり、プログラマ時代のはじまり - Syoichi's Tumblr

    youkoseki: 概要:スマートフォンやタブレットの人気によりPCの果たす役割は小さくなりつつあるが、これにはプログラミング環境を失うという側面もある。一方でプログラマに対するニーズは今後も高く、このギャップを埋めることにビジネスチャンスがある。 hpがPC事業を切り離すという発表は驚きをもって迎えいれられた。なんといってもhpは世界シェアナンバーワンのPCメーカーで、20%弱ものシェアを誇っている。しかし量販店に行けば誰でも、最新のPCが昔では考えられないような安い値段で叩き売られているのを目にすることができる。PCはもはや儲かるビジネスではない。アップルはスマートフォンとコンテンツストアのビジネスへ変質した。デルは次々とITサービス企業を買収している。NECのパソコン部門はレノボとの協業でなんとか道を見出そうとしている。AsustekやAcerといった企業でさえ、タブレット端末など

    PC時代のおわり、プログラマ時代のはじまり - Syoichi's Tumblr
  • 本の虫: 記録からみるLinus TorvalsのC++観

    On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > Gitのソースコードを始めてみた時、2つのことが頭にひっかかった。 > 1. C++じゃなくて純粋なC。理由は不明。移植性とか言わないでよ。 > クソだ。 クソまみれなのはオメーの方だ。 C++は悲惨な言語だ。しかも、少なからぬ数のプログラマーが使っていて、完全無欠のどうしようもないクソを生成するのがめちゃめちゃ簡単になっているという点で、よけいに悲惨だ。マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。 つまりだ:Cの選択は唯一のまともな選択なんだよ。Miles Baderがふざけて、「いやがらせによる追い返し目的」なんていってたが、実際のところ正しい。俺の出した結論では、プロジェクトにCよりC++を使いたがるプログラマーは、む

  • 考えるべき改善の方向性 - rabbit2goのブログ

    ソフトウェアの品質を上げるための改善策を議論すると、決まって「チェックリストを追加しましょう」「確認作業を行いましょう」「仕様書を作成しましょう」など追加作業が必要になることが多い。確かに今まで何か足りないモノが有ったから問題が発生したわけで、その対策を打つために何かアクションが必要になるのは分かるけど、そもそも時間が足りないから作業が出来ていなかったはずだ。それなのに、さらに時間が必要になるアクションが解決策になるのは変な話だと思う。 「疲弊する開発者」でも書いたように、現場の開発者はあれをやれ、これをやれと言われ続けて疲れている状態だ。だから、作業の積み増しはもう不可能なのだ、そこで、必然的に解決策の方向性も、もっと作業を減らす方向に向かなければならない。例えば、こんな方法を考えるべきではないだろうか? もっと手を抜く方法 もっと安上がりな方法 もっと短時間で済む方法 もっと簡単な方法

    考えるべき改善の方向性 - rabbit2goのブログ
  • 疲弊する開発者 - rabbit2goのブログ

    前回([id:rabbit2go:20080601:1212326562)に続き、ソフトウェア品質改善委員会に参加。隣の事業部がやっているから、という安直な理由で設置された委員会だが、経験者が揃っているのであーだこーだと議論は盛り上がる。しかし、自分がコードを書いていて時代の技術しか知らず、今の現場で起こっている問題を正しく把握できていなかったりするので、ひたすら空虚な主張が続く。曰く、 設計書のレビューはきちんと行うべきである。 ソースコードのレビューはきちんと行うべきである。 割り込み作業が入って場合、工程の見直しを行うべきである。 仕様変更は関係者の事前合意を得るべきである。 進捗確認はきちんと行うべきである。 そんなことを実践できるのなら、もうやっている。組織の開発体制として、そのような作業が出来ない(許されない)やり方を続けているから、問題が山積み状態になってしまうのだ。そもそも

    疲弊する開発者 - rabbit2goのブログ
  • 品質改善会議にて - rabbit2goのブログ

    品質管理担当:「...というわけで今回の開発のバグ発生件数、発生率とも前回のバージョンと同じレベルです」 偉い人:「品質が改善しないのは何故か?」 私:「前回の開発以降、改善の努力を何も行っていないからです。技術力向上の勉強会は前バージョンの不具合対策のため延期、外部講師を呼んでの社内セミナーは予算削減のため中止、前回の不具合の原因調査は仕様変更で人手が取られたため保留、開発者は忙しくて勉強する暇もないし、割り込み作業が多くて品質改善に取り組む余裕がありません。こんな状況なら品質が改善しなくて当然です。むしろ、品質が低下しなかった分、喜ぶべきです」 全員:「...」 以前のエントリid:rabbit2go:20080501にも記載したように、同じ人が同じ技術仕事を進める限り、アウトプットとして出てくる品質も同じです。そんな状況を放っておいて品質が改善するわけありません。なんでこんな当たり

    品質改善会議にて - rabbit2goのブログ
  • 歴史は繰り返す - rabbit2goのブログ

    或るソフトウェア開発の歴史。(これはフィクションです) ソフトウェア製品を開発する。 長年に渡って機能拡張、仕様追加を繰り返し、充分な動作実績を獲得する。 やがて綺麗なソースコードの構成は崩れ、メンテナンスが難しくなる。 経験と実績を生かして、今までの問題を全て解決した新しいソフトウェアを新規開発することに決まる。 しかし、昔のソフトを参考に作っているので、だんだんと仕様・設計が似てくる。 結局、出来上がったものは昔のソフトウェアと同じ。それどころか、以前のソフトでは使えていた機能が無くなったり変わっているのでユーザからクレームを受けるハメになる。新規開発なので品質も安定せず、「昔のソフトの方が使いやすかった」等と酷評される。 同じ人が同じ思考で同じように作る限り、出来上がるものも同じになってしまうのは当然の帰結でしょう。当たり前のことですね。酷い場合だと、開発者の世代が入れ替わっているの

    歴史は繰り返す - rabbit2goのブログ
  • C/C++開発環境 - Qiita

    Windows/Linuxで両方で動作する成果物を想定。 有償のツールは理解が得られる方が稀なので除外。 仕様書 外部仕様 Word/Excelが手軽だけど差分が追いにくい。 Markdown+PandocかSphinxでPDF提出がいいかな? Pandoc - About pandoc Sphinx-Users.jp :: ドキュメンテーションツール スフィンクス Sphinx-users.jp 内部仕様 きちんと書いてあればDoxygenで十分だと思う。 Cしか対応していないみたいだけどdocuriumの方がgitとの親和性が高くて(tag付された結果をまとめて解析してくれるみたい)出力結果も今風にできてる。 Doxygen github/docurium インセプションデッキ 作っておくと上司/部下/協力メンバで方針を合わせやすい。 ネスケラボ » インセプションデッキ ソースコード

    C/C++開発環境 - Qiita
  • Pandoc - index

    If you need to convert files from one markup format into another, pandoc is your swiss-army knife. Pandoc can convert between the following formats: (← = conversion from; → = conversion to; ↔︎ = conversion from and to) Lightweight markup formats ↔︎ Markdown (including CommonMark and GitHub-flavored Markdown) ↔︎ reStructuredText → AsciiDoc ↔︎ Emacs Org-Mode ↔︎ Emacs Muse ↔︎ Textile → Markua ← txt2t

  • Sphinx-Users.jp

    Sphinx-Users.jp¶ Sphinx-Users.jp(略称#sphinxjp)は、美しいドキュメントを簡単に生成することができるドキュメンテーションツール、 Sphinx (スフィンクス)の普及を主眼としたコミュニティです。SphinxはPythonの公式ドキュメントだけでなく、このSphinx-Users.jpのサイトも含め多くのマニュアルやサイトで使用されており、詳細を Sphinxの歴史で紹介しています。 Sphinx-Users.jp は日の Sphinx コミュニティです。 Sphinx-Users.jp では、日で散らばっているSphinx関連情報を集めて、Webサイト、イベントを通じてSphinx情報を発信します。 slack のコミュニケーションや勉強会の開催などを通じて、ドキュメントをパワーアップしたい人、ドキュメントや翻訳で苦労している人、Sphinxの

    Sphinx-Users.jp
  • 全てのプログラマーが、一度は経験ある事 【海外の反応】 : 海外の反応プリーズ

    2013年05月09日01:50 全てのプログラマーが、一度は経験ある事 【海外の反応】 カテゴリ海外の画像 Comment(34) 海外のサイトにて、 「全てのプログラマーが、一度は経験ある事」 といった内容の画像がアップされ、話題になっていました。 それでは、どうぞ御覧下さい。 ttp://www.reddit.com/r/funny/comments/1dxec2/at_some_point_all_programmers_will_experience_this/ この画像に対する海外の反応です。 ・ああ・・・しかも2番目のケースの方が、1番目よりもずっと恐ろしいんだよね。(笑 ・「一度は」だって? アハハハハ、俺は毎日こんな感じだよ!(泣 ・2番目だけが、毎日起こってくれればいいのになあ・・・。 ・怖いほどに真実。 ・俺は毎回こんな感じ。 「まあいいや、後で調べよっと」 ・俺がよ

    全てのプログラマーが、一度は経験ある事 【海外の反応】 : 海外の反応プリーズ
  • 標準ライブラリで提供される便利な機能

    #include <stdlib.h> #include <string.h> #include <stdio.h> #include <stddef.h> int main ( void ) { char *decimal = "0123456789"; // 文字列 decimal から文字 3 と 7 の位置を探す。 char *three = strchr(decimal, '3'); char *seven = strchr(decimal, '7'); // 文字 3 と 7 のポインターの差を計算する。 ptrdiff_t diff = seven - three; // Visual C++では書式文字列を "diff = %Id\n" とする。 // diff = 4 printf("diff = %td\n", diff); // three + diff = 7 pr

    標準ライブラリで提供される便利な機能
  • SourceMonitor

    SourceMonitor Version 3.5 NOTE: The author of SourceMonitor is retiring and the current version of SourceMonitor has been released as open source. The open source version of SourceMonitor, along with information on support, is available here.

  • Cello • High Level C

    #include "Cello.h" int main(int argc, char** argv) { /* Stack objects are created using "$" */ var i0 = $(Int, 5); var i1 = $(Int, 3); var i2 = $(Int, 4); /* Heap objects are created using "new" */ var items = new(Array, Int, i0, i1, i2); /* Collections can be looped over */ foreach (item in items) { print("Object %$ is of type %$\n", item, type_of(item)); } /* Heap objects destructed via Garbage

  • 昨今のWebアプリケーションのひな形その2 - Grunt - naoyaのはてなダイアリー

    昨日の続き。 こういうアプリケーションのテンプレートを管理するのに便利な仕組みはないですかねーと言っていたら @teppeis さんや @omo2009 さんに Grunt や Yeoman はどうかと教えてもらった。 Grunt はユースケースとしては JavaScript の連結や圧縮、SCSS/LESS なんかのメタ言語のコンパイルをするときに使うもの、つまり rake なんかと同じようなものと以前にチラ見した程度で知った気になっていたけども、ちょっと違っていた。Grunt は確かにタスクランナーではあるのだが、Node.js で実装している利点を十分に活かして、任意のファイルが更新されたのをトリガに一連のタスクを実行させたり、Grunt で Webサーバーを立ち上げて他のタスクと連携させたりといったことができるようになっている。プラグインの仕組みがあって、エコシステム的に結構活発に

    昨今のWebアプリケーションのひな形その2 - Grunt - naoyaのはてなダイアリー
  • 昨今の自分用Webアプリケーションひな形 - naoyaのはてなダイアリー

    ちょっと jQuery と簡単なサーバサイドの処理を組み合わせた処理を試しに書いてみよう・・・なんて時に、いちいち jQuery を取ってきて HTML を書いて script タグを書いてロードして sinatra 立ち上げて云々・・・というのが毎度面倒なので、ひな形になるアプリケーションを作った。 https://github.com/naoya/boilerplate ひとまず sinatra でサーバーサイドを書き、HTML は slim で、CSS は sass 。JavaScript は CoffeeScriptで書くにあたって jQuery、underscore、Backbone をロードしてある、というような構成にしてあります。 まあ、この類のことは人それぞれ自分なりにカスタマイズしてやっていると思いますが、どういうコンポーネントで構成しているかを、備忘録も兼ねてちょっと紹

    昨今の自分用Webアプリケーションひな形 - naoyaのはてなダイアリー
  • JavaScriptの落とし穴

    4. JSのオブジェクトは 連想配列みたいなもの 1 // 空のオブジェクトを作成 2 var dog = {}; 3 4 // プロパティをひとつ追加 5 dog.name = "Pochi"; 6 7 // ブラケットでもアクセスできる 8 dog['breed'] = "Shih Tzu"; 9 10 // 関数をひとつ追加 -> メソッド 11 dog.getBreed = function () { 12 return this.breed; 13 } 5. JSのオブジェクトは 連想配列みたいなもの 1 // 同じものをオブジェクトリテラルで表記 2 var dog = { 3 name: "Pochi", 4 breed: "Shih Tzu", 5 getBreed: function () { 6 return this.breed; 7 } 8 }; 6. クラスっぽい

    JavaScriptの落とし穴
  • 開発に役立つ,BATファイルの書き方・パターン集 (コマンドプロンプトの定石を体系的に学び,バッチ中級者になろう) - 主に言語とシステム開発に関して

    バッチのまとめTOPWindows上の処理を自動化するプログラムが,BATファイルである。 「コマンドプロンプト」上での手作業を省略し,自動実行できる。 Windowsが存続する限り,BATファイルはなくならないだろう。 バッチ・プログラミングの需要は,何があろうとこの先生きのこる。 このWindows 10の時代でもそうだ。 BATは,MS-DOSの時代から長く使われてきた。 そのため,各コマンドに関する個別のノウハウや情報は多い。 だが,実用的なノウハウを体系的に整理したものは,あまり見かけない。 そこで以下では,BATをコーディングする際の良質なパターンを列挙する。 (0) BATプログラミングの特徴 (1) BATファイルの雛型 (1−1) 冒頭と末尾のテンプレート (1−2) 反復して実行可能に (2) バッチの構造化 (2−1) ルーチンの分割 (2−2) 実行ファイルや実

    開発に役立つ,BATファイルの書き方・パターン集 (コマンドプロンプトの定石を体系的に学び,バッチ中級者になろう) - 主に言語とシステム開発に関して
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • Androidの通信周りのコーディングについて

    6. JSONやXMLのパース { “id” : 0, “name” : “tsubu”, “place_name” : “a-team” } public class Meeting { private int id; private String name; private String placeName; public void setId(int id) { this.id = id; } public void getId() { return id; } // (省略) } JSON POJO パース(デシリアイズ) シリアライズ 7. パーサーを書く public class MeetingParser { private interface Key { String ID = “id”, String NAME = “name”, String PLACE_NAME =

    Androidの通信周りのコーディングについて