2016年12月現在、Atomには1800近いテーマがアップロードされています。その中で良いテーマを吟味する時間や労力は大変なものです。そこで、この記事では私が選んだおすすめテーマを一挙に紹介していきます！ テーマのリンクとサンプル画像、そして今回は寸評も書いてみました。寸評は多分に個人の感想が入っているので、あくまでも参考程度に。 夏にもおすすめテーマをあげているのでそちらも合わせてご覧ください！ niisi.hatenablog.jp 目次 目次 オススメダークテーマ オススメライトテーマ 四季テーマ イロモノテーマ おわりに オススメダークテーマ プログラマといえば、エディタの背景は黒色というイメージがありませんか？ 長い間エディタとにらめっこしていると明るい色だと疲れやすいような気がして、私はよく黒色背景のテーマを使用しています。また、同じ系統のテーマでもライトとダークだと黒色背景

はじめまして、teaeastと申します。 非エンジニアで、スマホゲームの開発にかかわっています。 完全に勢いでアドベントカレンダーに登録したのでおびえています。 いじめないでください。 そんな感じで、非エンジニアの私がAtomを使いだした経緯と所感について書いていこうと思います。 導入の経緯 SublimeTextとの出会い 現在ではあまりやっていませんが、以前の職場ではプランナーもスクリプトを打つ必要がありました。 といってもゲームの実装でどうしても必要な部分だけ書くといった感じ。 学校でプログラムをやったことなどなく、途方に暮れていた私に同期のプログラマーさんが教えてくれたのが、かの有名な「Sublime Text」でした。 恋するエディタの名前通り、めっちゃ使いやすかったです。 見た目から入る派かつ、フォントスキーな私はまずUIに一目ぼれ。 以来、多岐にわたって使用していました。 S

本エントリは おうちハック Advent Calendar 2016 の25日目です。おうちハックAdvent Calendarは今回で3年目なのですが、3年連続ですべてのカレンダーが埋まりました！記事書いていただいたみなさん、読んでくださったみなさん、ありがとうございます！今年はhomebridgeとMESHが人気だったかな。 私は、いままであまりまとめる機会がなかった「おうちハック同好会」のはじまりや、活動の動機などについて書いてみました。ちなみに、「おうちハックはどこから来て、どこへ行くのか」というタイトルは、先日のMashup Awards FESTAのコミュニティ対抗LTの発表タイトルとしてつけたものだったのですが、LTではあまり深い話をしなかったので、このタイトルに正しく沿った話をしたいなあと思い、このエントリのタイトルにしました。 はじまり まず、「おうちハック同好会」という

これは　おうちハック Advent Calendar 2016　16日目の記事です。 はじめに おうちを改造して便利で愉快な暮らしを送りたい。でも、現実のおうちにはいろいろな制約がある。狭いとか、壁紙を毎日取り換えられないとか、ペットが飼えないとか、アニメのキャラクターが3次元で存在できないとか、ともかくいろいろだ。もちろん、制約の上でよりよい解決策を求めハックをするというのは楽しみだ。が、今回はその制約自体を取っ払ってしまおうという試みをしたい。 現実のおうちでできないなら、おうちを仮想世界にもっていけばいいじゃない。世はVR元年、我が家にもHTC VIVE がある。これを生かさない手はない。現実と仮想のおうちを行き来し、ハックする未来のための第一歩として、VR空間内に自分ちの部屋を再現したいという野望のもと、ゲーム作りとかやったことない主婦が今日1日でできたところまで書きたい。(正確に

この記事はおうちハック Advent Calendar 20167日目の記事です。（遅刻ゴメンなさい・・！） 「マイコンボードってなに？」というIoT超々初心者のウェブエンジニアがやっちまった話をします ことの発端 IoTLTというIoTの成果物を持ち寄るイベントで、がじぇるねの方に「使ってください！」とマイコンボードをいただきました。 マイコンボードを見るのはこの時が初めて！ Webコンパイラでかけるよ 有線LANが直接させるよ という初心者向けなボードをいただいたようです。 ピンクでなんか可愛いくらいしか正直わからなかった。 実現したかったこと 「お風呂が溜まったら知らせてくれる装置」 身近なIoTといえばおうちハックなので、ずっと困っていたことを解消することにしました。 水はセンサー+マイコンで割となんとかなりそう とりあえず有線LANでサーバに飛ばせそう 給電もとりあえずなんとかな

概要 我が家ではエアコンをリモート制御することができるようになっています 所謂 IoT の波に乗り遅れないようにまずは身近なところからハックということでエアコンを IoT 化してみました 一ヶ月ほど実運用してみたのでレポートを書いてみました コスト まずは気になるコストですが、以下の通りです 開発費用 約 3,020 円 マイコン ( 2,200 円 ) USB ケーブル ( 200 円 ) 赤外線 LED ( 100 円 ) タクトスイッチ x 2 ( 20 円 ) 各種電子部品 ( 100 円 ) ブレッドボード ( 400 円 ) ランニングコスト 0 円 です 自宅のネットワークは WiMAX2 を使っておりそれは昔から使っていたので今回のコストには含めていません (今回の IoT 化作業でかかったコストではないため) ということで約 3,000 円で実現した IoT です 仕組み

Phase 0 There’s no difference between testing and debugging. Other than in support of debugging, testing has no purpose. 『テストとデバッグには何の差もない。デバッグ以外にはテストに目的はない。』 Phase 1 The purpose of testing is to show that the software works. 『テストの目的は、ソフトウェアが動くということを示すことである。』 Phase 2 The purpose of testing is to show that the software doesn’t work. 『テストの目的は、ソフトウェアが動かないということを示すことである。』 Phase 3 The purpose of testing

はじめに プログラマの中には、TDDのような自動テストを整備すれば、手動テストは必要なくなると考えている方もいるようです。本記事では、主にプログラマー向けに、手動テストの大切さとはじめ方を書きます。 はじめ方に忍者式テストが出てきます。 プログラマーが得意なテスト、不得意なテスト プログラマーはCheckingが得意です。Testingは不得意です。 テストには Testing と Checking の二つの作業がある Michael Boltonという人のお言葉があります。 Testing vs. Checking « Developsense Blog Checking Is Confirmation Testing Is Exploration and Learning テストにという行為はCheckingとTestingの二つの行為の分けられます。 Checkingは既知の不具合が

Android Advent Calendar 2016 3日目の穴埋めです。 普段は社内でお菓子売って生計を立てようとしているdanekoです、こんにちは。 残念ながら全く成り立たないので、Androidアプリ開発したりしてます。 なぜか手元に未投稿のAdventCalendar用のやつがあったので放流しておきます。 内容としてはAndroidアプリで、ほぼ役に立たないTipsや、最近ハマった点を幾つか紹介したいと思います。 やむを得ない仕様のJsonのParseをLoganSquareでやる LoganSquareというJacksonのstream APIを利用したライブラリです。 またDocumentでは触れられていませんが、GenericsなModelにも対応しています。 (使い方としてこのtestコードがわかりやすいかと) 日本語の概要としては、Androidの高速なJSON パ

4日目を担当させていただきます @sakebook です。 Androidアプリ開発において、Googleの影響力は絶大です。そんなGoogleがストアにアプリをいくつ公開しているかご存知でしょうか？ 自分の環境で見たところ、100件以上のアプリが公開されています。 現状のAndroidでどんなことができるのか？自分では思いついていないようなことや、できないと思っていたことでもできたりするかもしれません。 どんなことが実際にできているのか、ストアに公開されているアプリを例に学びます。 Google Inc. Expeditions VRコンテンツを、引率役のガイドと、引率される探索ユーザのグループで同時に体験することができるアプリです。ベストイノベーティブアプリ部門にノミネートされています。 コンテンツ自体はAndroidで作るものではないですが、Expeditionsアプリと連携すること

Android Advent Calendar 2016 の 5日目を担当します @kobakei です。 Androidの設計やアーキテクチャの話となると、MVC, MVP, MVVM, Reduxなど色々なパターンが試されているものの、万人が「これを使っとけば間違いない！」的なものはまだない印象です。 この記事では、どのパターンがいいか／悪いかみたいなマサカリが飛びそうな話題はせず、Android初心者が最低限これくらいはやっといたほうがいいよという設計を紹介します。 ※shibuya.apk 11で話した内容をベースにまとめています。スライドはこちら。 モデルとビューを分ける それぞれのMVX系パターンはプレゼンターやビューモデルなどの責務は異なっていますが、「モデルとビューは別」という点は共通しています。なので、少なくともモデルとビューは分けてしまいましょう。 Androidの場合

特別なパーミッションとは Android にはパーミッションと呼ばれる仕組みによって、アプリがユーザの許可無くプライベートなデータやセンサ類などにアクセスできないようになっています。Lollipop まではストアでのインストールと同時に許可を与えるフローでしたが、Marshmallow 以後は Runtime Permission という仕組みが導入され、アプリを起動してからユーザに許可を求めるフローへと変わりました。 さてこの記事では、その Runtime Permission のフローとは更に別なフローを経なければ許可ができない特別なパーミッションについてまとめます。この特別なパーミッションに対する許可を得るには、ユーザを然るべき画面へ遷移させ、システムの設定画面をつかった許可フローへナビゲートする必要があります。Runtime Permission ではダイアログが表示されましたが、

この記事は「Qiita Advent Calendar 2016 Android その2」の10日目の記事です。 自己紹介 私は、株式会社サイバーエージェント CA ProFit-X という広告プロダクトで、メディア様の収益を最大化することを目標にエンジニアをやってます。 CA ProFit-X は、モバイル向けネイティブ広告（主にインフィード広告）専業のSSP事業者なのです！ また個人的には、今年から 日本Androidの会 の運営メンバーにも入ってたり。 お題 今回はテスト自動化を目標に、 Appium に手を出し始めた話しをしたいと思います。 Appiumって？ Appiumとは、iOSおよびAndroidプラットフォーム上で動く - ネイティブアプリ - モバイルウェブサービス - ハイブリッドアプリ 等を自動化するオープンソースのツールです。 実践 Appium 作者: Mano

Androidその２ Advent Calendar 2016 - Qiita 17日目の記事です。 Android アプリ開発 平素よりお世話になっております。 Android アプリの開発では色々なプロジェクトを横断したベンチ要員役をすることが多いのですが、ベンチ要員から見るスタメン選手の大変さについて改めて考えると、ベンチを温める身ではありますが、経験からスタメン枠の負担をうまく減らせるのではないか？と思っています。 そんなベンチ要員の Android アプリ開発で見聞した何かをここに吐露していこうかと思います。 ベンチ要員って? いろいろな定義があると思うのですが、自分が思うベンチ要員とは 「スタメンの誰かに怪我や病気のアクシデントや、累積イエローの出場停止や、他のリーグや国際試合などで試合に出られない場合に、代わりにポジション/職務を受け持つ係」 のことだと思います。 他に「2番

iOS その2 Advent Calendar 2016 15日目の記事です。 現在業務で製作中のアプリではClean Architectureを採用しています。アプリ自体はまだリリースされていないのですが、少しずつ全体像は見えてきたのでClean Architectureの概要と合わせて具体的な実装例の紹介と現時点での所感などを書きたいと思います。 Clean Architecture とは 概要 iOSアプリにおける実装 3つのグループ分け Presentation Domain Data 所有関係・依存関係 Clean Architectureから外れたもの メリット・デメリット メリット テスタビリティが向上する 再利用性が向上する 機能を置き換えやすくなる 見通しが良くなる デメリット 学習コストが高い 面倒なことが多い ライブラリやSDKの設計思想と食い違う 最後に 参考文献

はじめに 本エントリーは、 Xamarin(その2) Advent Calendar 2016 の13日目です。 Tizen の.NET対応の発表について 記憶に新しい Connect(); 2016 では様々な発表がありました。 connectevent.microsoft.com 皆さんは何が一番のサプライズでしたでしょうか。 もちろん Xamarin.Forms.Platform.Tizen の発表ですよね。 そこで、本記事ではTizenの.NET対応についての始まりとこれからを探っていきたいと思います。 MonoTizen Xamarin.Forms.Platform.Tizenが初めての.NET対応ではありません。 Tizenの.NET対応としてMonoTizenが世に出ています。 MonoTizenの誕生 2014年5月20日 Kitsilano Software がMonoT

こんにちは。エクセルソフトの田淵です。 本エントリーは 初心者さん・学生さん大歓迎！ Xamarin その2 Advent Calendar 2016 の 12日目の記事です。 昨日はサンテアさんの Xamarin.Forms におけるマルチウィンドウの落とし穴 - ぴよぴよエンジニアの日記、明日は Nuits です！よろしくお願いいたします。 Xamarin を始めるにあたって、Xamarin の概要と、初めての方が気をつけておいてほしいこと、試してみて欲しいことなどを纏めたいと思います。どうぞよろしくお願いいたします。記載内容の補足として、日本語での解説記事やブログなどがにリンクしていますので、是非リンク先もご覧ください。ではよろしくお願いいたします。 Xamarin ってどんなものなの？ C# だけで iOS／Android／UWP／Mac のアプリを開発できるフレームワーク、統合開

よくよく考えたら、私１個もXamarinアプリを完成させたことないので、初心者だと思います。 てことで本エントリーは[初心者さん・学生さん大歓迎！] Xamarin その2 Advent Calendar 2016 - Qiitaの12月13日分になります。 明日はmuak_xさんです。よろしくお願いします！ なお、本エントリーは「私がXamarinを選びたい理由」ということで、あまり技術的な話ではないです。ポエムです！ポエム！ さて、個人の趣味は別として、私が仕事で使いたい一番の理由は実のところ 「スマートデバイスのクロスプラットフォーム開発環境」としてのXamarin にはありません。 一般向けの「Xamarinはいいぞ！」はさておき、自分自身がなぜXamarinにフォーカスしたいのか？自分の都合を書いてみたいと思います。 泥臭い話になりますが、たまにはそういうのも良いかと思い書いてみ

自己紹介 あすかです。 どこにてもよくいる、こくふつうの男性会社員です。あと、おみみ聞こえません。 きょねん、かいしゃにはいりました。２ねんめです！しようしょ、つくったり、てすとしたり、かいはつしたり、してます！ 趣味は、プログラミングと、おええをかくことです☆ 新都社というところで漫画を描いているのですが、ストーリーを考えるのが苦手で、いつも苦労しています。 面白い話を描きたいけど、面白くてかつそれなりにまとまった物語を描くためには、話をまとめるためのソフトが必要だと思いまして、作りました。 今回は、そのアプリを作ったときのお話をちょっと。。 アプリの概要 今回制作したアプリは「StoryCanvas」 Windows、Android、iOS上で動作する、ストーリーに出てくる登場人物、シーンなどの設計に特化したアプリです。 公式サイト：https://storycanvas.kmycod

これは[学生さん・初心者さん大歓迎！]Xamarin Advent Calendar 2016 - Qiitaの23日目の記事です。 前日は 普段Swift書いてますがXamarinに入門してみました ｜ Developers.IO でした。 今回、本当はXamarin Studio Addinについて書こうとしたのですが、Xamarin Studioにブチ切れた諸々の諸事情により書く時間が足りなかったので思いっきりネタに走りました。本当に誰得レベル。 最近Xamarin.Forms書いてないし(専らNativeのほう)、そういえば私も1本もアプリ作れてないので初心者だと思います。なので、入門に向けてXamarin.Forms上でHello Worldをやってみました。 目指すのは以下のような感じ。 大事なことなのでもう一度いいます。ネタです。 環境 macOS Sierra Xamari

このエントリーは、[学生さん・初心者さん大歓迎！]Xamarin Advent Calendar 2016の19日目です。 はじめに タイトルの通り、Xamarinの超初心者です。 未だにPCLとSharedの違いがイマイチ理解できていません。。。 鋭意勉強中です！ そんな私がXamarinを勉強し始めた時に作ったアプリ（と言っていいものかはさておき）に題材とした「ライフゲーム」を紹介します。 ライフゲームとは Wikipedia先生によると生命の誕生、進化、淘汰などのプロセスを簡易的なモデルで再現したシミュレーションゲームとのことです。 詳しくは、ライフゲームを見てもらえるとわかると思います。 なぜライフゲームなのか？ 一番の理由は、私の大学の時の卒論の専攻が複雑系工学と言うものだったからです。 複雑系とは、個々がそれぞれの役割を担い関係しあうことで全体的に本来の機能を実現するもので、川

本エントリーは [学生さん・初心者さん大歓迎！]Xamarin Advent Calendar 2016 の 13日目の記事です。 初心者向けの記事ということでXamarin初心者なりに「こういうのってどうやって実装するんだろう」って思ったことについて書かせていただきます。 タイトルに各プラットフォーム固有機能とかありますが 頭蓋骨骨折とかして時間が足りなくて Androidだけです。折角なのでiOSやUWPも別の機会に書こうとは思います。 以下記事が今回の記事を書こうと思った動機のようなものです。 Xamarin.Formsで通知を出す(Android)(Prism.Forms使用) また、今回の記事は上記記事同様基本的にPrism.Formsを使用した際の記法で記載致します。 本題です。 Xamrin.Formsでの開発していくにあたり共通部分だけではなく各プラットフォーム固有の実装の

転職 Advent Calendar 2016 - Qiita の7日目です。 エンジニアにとっての一大イベント、「転職」。 そんな転職の助けになるかどうか分かりませんが、４回転職した平凡なエンジニアの転職談を書き綴ります。 １社目：老舗の下請け会社 関西にある老舗の下請け会社に新卒として入社しました。 業務としては 某大手SIerの下請け（主に一次請け） 自社製品の開発（そんなに売れてない） という感じでした。 ただ、私の配属された部署は所謂SESをやっていて、在籍していた２年間はほぼ他社でテスト要員として働く毎日。 そもそも面接時に「Webのお仕事やらせてあげるよ」と聞いていたのに、やっていることと言えばExcelにスクリーンショットを貼り付けてファイルに日付を書くという、猿でも出来るようなお仕事でした。 本当にこの２年間はエンジニアとして何も成長せず、無駄なキャリアだったなと今でも後

転職 Advent Calendar 2016 17 日目です！ この記事を公開しているのは12/8なので完全にフライング、今日読んでもらいたい相手がいるので公開しますが、問題あれば消します。 記事を書くきっかけ 友人とメシを食べて、転職するかどうするか〜みたいな話をしていた。 自分は今年の10月に転職したばかりなので、迷っているのは話し相手の方である。 いろいろ話した後に歩きながら「転職活動それ自体のメリット」など話せば良かったなと思ったので、相手に伝えるとともに自分の思いを公開する。 転職活動のメリット 転職というと職場環境が変わり最高 という話もあるが、それとは別に 転職活動という行為それ自体 が自分自身にとって大変良かった。 転職活動をすると、自分の市場価値を図ることができる。 現時点の自分の価値は果たしてどれだけのものなのか？ 自分が培ってきたスキルや仕事への姿勢などは、他社では

概要 こんにちは、若干このアドベントカレンダーの空気が読めなくて困惑している @takano32 です。 何か転職とかに役立つ話を書こうと思ったんですが、釣りタイトル出オチです。 時間がなかったので少ない文章にしようと思った 技術っぽい文章にはしたくなかった 少ない文章とはいえ、何かそれなりにネタになりそうな話をしたかった アドベントカレンダーの内容を見ていたら思いのほかポエムが多くて、私も何か壮大なポエムを書かなくてはいけないような気になったんですが、ちょっとムリそうなのでせめて情報量で許してもらおうと思いました。 結論 新卒で大手電機メーカーに就職してから、現在の会社で三社目になりますが、自己都合退職は一回です。ほら、僕は自己都合退職が少ない。おしまい。 自己都合退職と会社都合退職 自己都合退職と会社都合退職の闇がよく分かりません。三社目ということで退職は二回になるわけですが、自己都合

はじめに この記事は転職Advent Calendar25日目の記事です。 僕は転職したばかりで今年の９月からUIデザインの会社でエンジニアとして働いています。 現在28歳ですが、20歳に新卒でソフトウェア開発会社に入社してから３度転職し、今の会社は4社目です。そういう意味ではジョブホッパーの類に入るかもしれません。 今回はトリという事もあるので、転職AdventCalendarの各記事で共感したもの、あるいは「なるほど！」と感じたフレーズ（あくまで僕個人の印象）を抜粋してみました。色々な転職の形があるので気になるフレーズがありましたら、ぜひ該当記事をじっくり読んでみてください。 また、最後に今後転職を考えている人向けに自分の転職に対する見解も踏まえて少しだけ書かせていただきます。 転職アドベントカレンダーハイライト 1日目：2016年内に2回転職した話とか 最初はどの会社にも夢を抱いて入

※ この記事は「Qiita ポエム Advent Calendar 2016」13日目の記事です。 ※ ポエムです。 ※ ポエムです。 俺が狂ったのは奴らのせいさ 般若というラッパーがいる。 現在ラップは日本史上で何度目かの市民権を得るチャンスの中にある。般若はその中心にいる。 2012年以来、高校生ラップ選手権、フリースタイルダンジョンといったテレビ番組をきっかけに、MCバトルという文化*1が大流行している。そして2016年現在、MCバトルは若手のラッパーがバイト暮らしから「ラップで食っていく」ための最高のステップになっている。そういった若手のラッパーにとっての現代のカリスマが般若である。 他方で、その般若もまた、彼がラップを始めるきっかけを創った90年代のカリスマラッパー達への敬意を歌っている。 ギドラ ブッダ 雷 ペイジャー俺が狂ったのは奴らのせいさ*2 ― 般若『最ッ低のMC』 若

最近は少し活動頻度も落ち気味ですが、自分は日本語版ウィキペディアで、管理者1やビューロクラットと言った特殊権限持ちとして活動しています。 Wikipediaを「閲覧する側」でいるだけでもそれなりには役に立つかもしれませんが、ページの「編集」ボタンを押すことから広がる世界は、本業のプログラマーをする上でも、その他のネット活動においても、かなり役に立っています。 著作権への意識、コピーレフト ウィキペディアでは、サイト全体にCC-BY-SAというコピーレフトなライセンスがかけてあります。そして、「ウィキペディアのサイト上で編集を行う」ことはすなわち「全世界にCC-BY-SAでドキュメントを公開する」ということになるわけです。 オープンソースのソフトウェアを改造して公開することと比べれば、ウィキペディア上で既存の文章を加筆修正するほうがずっとハードルが低いこともあって、こちらでコピーレフトの世界

はじめに これは「ポエム Advent Calendar 2016」8日目のポエムです。 前提 このポエムにおける「プレイングマネージャー」とは、ソフトウェア開発の現場に限定した話です。私が生粋のエンジニアなので他の業界についてはわからないので。 プレイングマネージャー病気カタログ 自分でやった方が早い症候群 プレイヤーとして認められて、プレイングマネージャーへ転向した人は多いと思います。そのため、メンバーの仕事の進め方、コーディングなどあらゆるところで自分ではこうやるのにと思ってしまう。 症状 メンバーの進捗が遅いと感じる 自分ならこうやるのにと思うことがある メンバーから上がったプルリクを全部書き換える メンバーが実装について自分に事細かに質問するようになる。メンバーとしては、いちいち指摘されるのが面倒なので予め質問するようになる。 対処方法 待つのもマネージャーの仕事です。メンバーが

サンタクロースからの業務委託が無事完了したので、ようやく記事の書き込みが出来ますｗ この記事はQiitaのAdvent Calendar 2016 「フリーランス残酷物語」の最終日です。 http://qiita.com/advent-calendar/2016/free_zankoku 根本的に考えると、昨年夏に新規の取引先開拓をしていた時に 質問された「プログラム書いていて楽しいですか？」の一言が気になります。 自分は小学校３年の時、「夏休み子供パソコン教室」で FM７７AV２０でF-BASICを触ったのが、人生で最初のコードです。 それから、小学校のクラスメイトが要らなくなった「ファミリーベーシック」を貰って、それで自作のゲームを作ったり、ベーマガ（BASICマガジン）のコードを入力していたりしてました。 中学の時に、MSX２＋を購入するために貯めておいたお金に、親から差額を借りて、

本記事は新人Advent Calendar 2016の1日目の記事です。 ツッコミ要素満載！？新人によるアプリ開発 新人研修で行ったアプリ開発について書いています。アプリ開発は新人2人がチームを組んで与えられた課題「新人営業が打ち合わせに使えるWebアプリ！」を開発しました。新人がチームでアプリ開発をしたら、３回戦争が起きました。しかも、ツッコミを入れたくなること間違いなし！ 相方紹介 相方は同じ部門の新人4人の中でも、トップを争う技術力の持ち主！ 技術力に乏しい自分にとって、非常に頼りになる存在です。 開発は以下のスケジュールで行いました。 自己紹介 とあるSIerの新人エンジニアをしています。研究開発部門で現在修行中です。主に、Python、Djangoでアプリ開発と機械学習の勉強をしています。学生時代にあまりプログラミングをしていなかったので、部門の技術レベルの高さに圧倒されています

新人エンジニア Advent Calendar 2016の7日目記事です。 当日になっても誰も書く雰囲気なかったんで、書いちゃいます。 そこ、パディングとか言わない 現在進行形で書いてるなうです！ライブライティングです！ なんだかドキドキしますね。私が。 はじめに 業務効率化という視点で、今日一日の業務を追っていこうと思います。 「業務効率化だけど、わざわざ言うほどでもない...」 そんな心の隙間を埋めていこうと思います。 ～9:00 通勤 果たして通勤は業務に含まれるのかの是非は、一度置いておきます。 朝の通勤ラッシュ混雑中の時間は、何もすることができず、人生において無駄な時間となりがちです。 朝の通勤ラッシュ混雑をいかに回避するか、私の工夫を載せておきます。 なお、「早く家を出ればいいんじゃない？」という指摘はスルーします。 事前準備 降車駅で、自分が乗る電車のどの車両が改札に最寄りな

はじめに Advent Calender2016 新人エンジニア に寄稿させていただきました。 社会人二年目のみやもとです。 大学では数学という、全くIT関係ないとも言えないところから、今は主にサーバサイドのエンジニア半分とエクセルおじさん半分を生業としています。 Qiitaなどで発信する機会と言うか時間がなかなか取れてないのですが、偶然にも25日が暇暇アンド暇だったかつ、いい経験にもなるだろうと思い参加させていただきました。 1年半かかってやっと自分が一番集中できる時間を認識し、その時間にやるべきことやるべきでないことが、なんとなーくわかってきたので書いてみたいと思います。 ここに書かれたことが少しでも皆様のエンジニア生活の糧となれば嬉しい限りです。 時間の使い方 はじめに認識すべきこと エンジニアたるもの「生産性を上げろ」と上から口うるさく言われるのは逃れられない運命だと思います。 生

はじめに Advent Calender2016 新人エンジニア に寄稿させていただきました。 社会人3年目の@SatouRyouです。 もうすぐ、3年目も終了しもうすぐ4年目に突入する状態で、新卒というには怪しいですが、 カレンダーが空いていたので入社した頃の話を投稿致しました。 投稿に至るモチベーションは21日目に軽く記載致します。 タスク公開術について 特段難しいことはなく、タスクや仕事に関する自分が持っている情報をどんどん公開していく仕事方法です。 これは、特別意識して始めたことではありませんでした。 単に、自分が社内ではお喋りな方で(同期に言わせると自分がいないと会社が少し静かになるそう)、 何かあると上司にすぐ話すようにしていただけでした(意識していませんが、割と大きな声で)。 これは、入社した時からやっていただったのですが、少し前から意外と効果のあることだったと、 気がついた

この記事は 筋肉 Advent Calendar 2016 8日目の記事です。 qiita.com 腹筋を割るために、3ヶ月前から色々やってきたので、いったんまとめておきたいと思い、筋肉Advent Calendarに参加しました。ダイエットが主目的の筋肉ビギナーによる記事なので、筋肉ガチ勢の皆様におかれましては、赤子の成長を見守るような優しい眼差しで見ていただけると幸いです。 なぜ腹筋を割りたいと思ったのか 社会人になってからゆるゆると体重が増え続け、ゆるふわボディになっている事実から目を背けていたのですが、1年程前に娘が産まれてから家族で写真を撮る機会が増え、ふっくらした自分の顔を見る度に、そろそろ痩せねばと思うようになりました。また、30歳がそろそろ迫ってきて、「20代のうちにやり残したことがないか」ということを最近よく考えるのですが、肉体的にもまだまだいけるうちに腹筋を割っておきた

はじめに この記事は、ポエム Advent Calendar 2016 15日目の記事です。 過去 半年前に入社したときのSQUEEZEのコードは、いわゆる不吉な匂いに満ちていました。 重複したコード 長すぎるメソッド 巨大なクラス 長すぎるパラメータリスト などなど。 ただスタートアップでスピード重視の開発をしていたので仕方なかったのだと思います。 現状 ※ まだバグゼロは実現してません。少なからずバグは存在しています。 サービスをよりスケールさせていくために、それに耐えうる品質が求められています。 バグゼロに向けて、現在次のような取り組みを行っています。 テストコードを書く エラートラッキング リリースサイクルを短くする 古いコードのリファクタリング・破棄 コーディングスタイルの統一 コードレビューの徹底 これらに関しては、バグゼロを実現した話とその後の顛末 - Cybozu Insi

ラリー・ウォールの言葉に、「プログラマーの三大美徳は、怠惰・短気・傲慢である」と言うものがあります。 怠惰については以前に考えてみましたが、今回は「短気」について考えてみます。 「短気」の意味 もちろん、この「短気」も普通の意味ではなく、プログラムの動作が遅いことを許容できない、という意味合いです。人間関係については短期になっても得なことはありません。 遅いことによる問題 遅いことそれ自体による問題 セキュリティ上の要請があって「遅い方がいい」プログラムもまれに存在します1し、ユーザーインターフェースのプログラムの場合は「ユーザーの反応速度に合わせる」必要がありますが、そういう場面でない場合、動作が遅いことに対してはデメリットしかありません。Amazonによれば、サイト速度が0.1秒遅くなれば、売上は1%低下するとされています。 負荷の問題 通信などの待ち時間が多くて遅くなっているプログラ

この記事はポエムアドベントカレンダーの遅刻記事となります。 内容は決まっていながら遅刻したので、「時間を守る」もエンジニアに不足しているものに入れておこうかと思います。 はじめに フリーランス某酷某語の人が登録していたりと、非常にアツいアドベントカレンダーがあったので、私も久々にエモり散らかしたいと思います。 今回は、人とやっていくにあたってエンジニアに不足しがちなものを網羅的に書いていきたいと思います。 主語はできるだけ大きくいきますが、あくまでも今までみてきた例の中での主観です。 エンジニアに不足しがちなもの 協調性 エンジニアといえば協調性のない生き物の代名詞のように扱われていますが、実際色々と問題があると思います。 まず第一に、エンジニアは何かと「正しさ」を主張しようとします。 彼らにとっては、その場で重要視するべきことがらや、コンテキストに関係なく、彼らにとっての「技術的」な正し

どうでもいい話 最終日にポエムを書くことにしたのはいいけれど、今年書いた Advent Calendar のいくつかは結果的にポエムになってしまったので、あえて「ポエム Advent Calendar」というくくりで何かを書くのは難しい・・・。 以下本題 たったの 2 いいねの記事 私が Qiita に初めて投稿した記事は恥ずかしながら Qiita 上ではたったの 2 いいねしかもらっていないのですが、その記事のコメントと追記を見ていただくとわかる通り Vim でおなじみ香り屋の KoRoN 氏に拾われていたりします。私の記事が日本の Vim 界の停滞を防いだかもしれません。 と、冗談はさておき、たまたまこの例は、私のような末端の職業プログラマでも名前を知っている KoRoN 氏が登場人物でありブログの記事にも引用していただいているのでやたら大きい話のように見えるかもしれませんが、いいねし

Qiitaの事務局から嫌がらせの様に、自分の記事が限定公開にさせられているので、 こちらに転載しておきます。 強制的な権力には負けない。抵抗するのが自分の主義なので。 ポエム Advent Calendar 2016　の6日目です。 http://qiita.com/advent-calendar/2016/poet ここはポエムを書く場所なので、ポエムを堂々と書きます。 # プログラミングとは？ >コンピュータのプログラミング（英: programming）とは、コンピュータプログラムを作成することにより、人間の意図した処理を行うようにコンピュータに指示を与える行為である。 https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0_(%E3%82%B3%E3%

1968年の10月、当時マサチューセッツ工科大学の院生だったパトリシアは論文執筆のために大きな辞書を頻繁に引かねばならなかった。 ある時彼女は自分の体が辞書の引きすぎで木になっていることに気付く。 それ以来彼女はパトリシア木と呼ばれるようになり、今も入力の長さnに対しO(n)の時間で語を引き続けている。 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

本エントリーは、2016年度、ポエムアドベントカレンダー2日目です。 qiita.com ボードゲーム会に参加したりすると「ツミホロボシ」という単語を良く聞きます。意味を聞いたらなるほどなぁ、と思いまして、そして、それは実はエンジニアにも通じるものがあるかなと思いましたので、そのところの思いをぶつけていこうかなと思います。 ボードゲーマーの「ツミ」 初期の頃のボードゲーマーにはあまり無いことだと思いますが、一部のボードゲーマーは「ツミ」を日々重ねてしまったりします。僕も日々「ツミ」を重ねてしまっています。 ボードゲーマーは「ツミ」を放置してはいけません。放置しておくと、どんどん「ツミ」が増えて酷いことになります。その「ツミ」を償わなければなりません。「ツミ」を滅ぼさなければなりません。 なんか良く分からないでしょうか、打ち滅ぼした「ツミ」を「ツミ」上げてみました。 そう「ツミ」というのは、

投稿が遅くなって申し訳無いです。出張のために早寝してました。 現在AM7:00。飛行機の中で書いてます。 はじめに これは システムエンジニア Advent Calendar 2016 の7日目の記事です。 新卒エンジニアがこの1年を振り返って、気の向くままに書く記事になります。 主にイベント毎のマインドの変化なんかを書いていきたいです。 (カレンダーの題意とは外れてると思いますが、ご容赦ください) 具体的に書きすぎると会社に怒られるので、ボカしながら書いていきます。 自己紹介 2016年新卒 → 学部卒。黒い画面を触り始めて10年くらいで、マウス操作が苦手。 いわゆる上流SIer → 下周りばっかりやってる(NW設計, 仮想化基盤構築など) やってることはほぼPoC →「いい感じに作って」と言われて、設計を考えて動かして見せる感じ この1年を振り帰って 学生時代→新人研修 大抵の会社には

これは何ですか？ システムエンジニア Advent Calendar 2016の10日目です。 9日目は@kencharosさんのシステム開発のアンチパターンでした。 明日11日目は@tenten0213さんです。 本当はこの投稿は12/10、土曜日なのですが、週末は家族で過ごす時間が多くて書く時間が取れないので12/9、金曜日にアップしちゃいます。 背景 私はSIerで15年働いている、聴覚障害を持つプログラマ兼システムエンジニアです。 プログラミングしているほうが好きなのですが、どうしてもお客様とやり取りし、システムの仕様を話し合って決めないといけない場面が出てきます。 お客様とのやり取りは当然、手話は使えませんので口話、あるいは筆談が主となります。 これを念頭に、以下を読んでいただければと思います。 困ることと、その解決方法 お客様が求めている内容が読み取れない 聴覚障害者といっても

システムエンジニア Advent Calendar 2016の12日目です。ふつうのプログラマとして書かせていただきます。 当初はSIな現場のドロドロした何かしらを書こうと思っていたのですが、 ネタが被ったので 現場で使える小手先芸のお話をしようと思います。単純作業に対する個人技の話です。 なぜ小手先芸なのか SIの現場では膨大な単純作業が待ち構えていることも少なくありません。 それらは手作業で心を込めて行うこともできます。 ですが、手作業にはミスもありますし、単純作業に時間を割いていると、あっという間に納期は来てしまいます。単純作業は効率良く済ませて、早く帰るようにしましょう。 さて、なぜ小手先芸なのかですが、技術を身につけるには時間と覚悟が必要です。覚悟はともかく時間は誰も与えちゃくれません。時間を作るためにも、軽く始められる小手先芸が便利なのです。 時間の余裕ができると、次の仕込みが

だから意味のない旧来の「詳細設計書」は消えてほしい、というお話。 前提 現場によって、いろいろと粒度や定義が異なるとは思いますが、この記事における旧来の「詳細設計書」とは、ソースコードに書くべき内容を日本語に書き下したものであったり、その「設計書」通りにソースコードを書けば正しいプログラムになることを前提にしている何か、のことを指します。 標記の件について 今さら私が主張するまでもなく昔から言われ続けていることではあります。 ささっとぐぐれば、いろいろな記事が出てきますし（以下は一例） 詳細設計書という名のゴミ | Gm7add9 「コーディングは設計か製造か」という考え方の違い - 人生は長い暇つぶし。 古くて著名なところでは、たとえばマーティン・ファウラーとか。 主張 なぜそのようなものが生まれるのか？ 経験上からは、やはりソフトウェア開発を「モノづくり」に当てはめている現場ほど「詳細

この記事は、システムエンジニア Advent Calendar 2016 - Qiita の２３日目の記事です。 昨日は @yy_yank さんの 気負わず普通にテストしよう でした。 明日は @koduki さんです。 はじめに 複数ユーザが触るアプリケーションを作る場合、同時にデータが更新された場合の制御は避けては通れません。 この制御はスレッドセーフとか同時更新とか色々な観点で考えないといけないのですが、いまいちそのあたり自分自身の中できれいに整理できていませんでした。 なので、この機会に同時に更新される場合の排他制御について、自分なりに整理してみました。 まえおき 説明に使用する言語は Java です。 説明のためにシーケンス図っぽいものを使っていますが、 UML の厳密な定義には従っていません。図が描きやすいからシーケンス図を利用している、ってだけなので厳密な記法ルールに従ってい

この記事は「ポエム Advent Calendar 2016」の 1 日目の記事です。 初日ということもあるので、ポエムとは一体何か、何故ポエムが必要なのかといった内容のポエムを書こうかと思います。 ポエムとは一体何か ポエムとは日本語で言うと「詩」ですが、ソフトウェア開発の分野ではより狭義に「表現の厳密性や定性・定量データを必ずしも重視せず、個人の思いや価値観をその人自身が適していると思った表現でそのまま文章化したもの」といった意味合いで使われます。 僕の観測範囲内でも多くの人がポエムを書いたり、それを通してチームビルディングや開発プロセスのマネジメントをしています。「ポエム駆動開発」などという言葉もあったり、このポエム Advent Calendar もあったりして、ある程度広く浸透しているように思えます。 その性質から明らかですが、ポエムは当然仕様書でも作業依頼書でもありません。そも

今年も彼女が出来ませんでした。 かれこれ2年ほど彼女がいません。 いや、クリスマスまでにできる可能性は、まだあるんじゃないか？ 彼女が出来ない理由を考える ・顔がブサイク ➡︎ これはどうしよもできない。 ・ファッションセンスがない ➡︎ 今地味に頑張ってる。 ・よく歩くのが速いと言われる ➡︎ これは改善できるんじゃね？ 彼女が再び出来た時に備えて、歩行速度を改善しよう そうしましょう。そうしましょう。 デートがうまくいかなかったら嫌ですもんね。 今回用いたもの ・CoreMotionFramework...センサーへのアクセス ・AudioToolboxFramework...バイブレーションを動かすため 今回はお手軽にiPhoneのセンサーを使って移動ステータスを判定して、走っていると判定されたらバイブレーションで警告するという簡単なアプリケーションで、歩行改善を狙います。 iPho

Help us understand the problem. What is going on with this article?

彼女つくれなかった ~LINEBotを試してみる(MessageAPI+AWS GatewayAPI+Lambda)~ By skycat 16 12月, 2016 No Comments Tweet Tweet記事のタイトルでいきなり落ちちゃってますが、 カノジョできないエンジニア Advent Calendar 2016 http://qiita.com/advent-calendar/2016/no-girlfriend こちらのカレンダーで、 彼女がいないなら創ればいいじゃない という題名で、彼女を作る予定でしたが、時間的に知識的にもいろいろ無理でした。 ということでのカノジョできないエンジニア Advent Calendar 2016、16日目です。 とりあえず時間もないのでそれっぽいものを作ろうと、 LINE MessageAPI + AWS GatewayAPI+Lambda

どうもカノジョできないエンジニアAdventCalendar2016の主催のたかぴーです。 まずはじめに、昨年はすみませんでしたm(_ _)m 今年は... そうなんです...またなんです...。 今年のタイミングは、このAdventCalendarを作った日でした。 というわけで 私はお星様になってしまったので、直接あったタイミングで「書きたかったー」っていってくれた 地球の重力に魂を縛られた民代表として、代打 @localdisk に書いてもらいました。 こちらです。 ご査収ください。 謝辞 ホンマすんませんでした。。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful infor

結論：定時に帰れないのはエラーログが赤色だからである 毎日嫌でも目にするコンソールの$\color{red}{\rm ERROR}$の$\color{red}{\rm 赤}$が エンジニアの精神を蝕んで 結果として作業効率が低下して 残業時間が増加してんじゃない？ という個人的な所感に基づいて書きます 定時に帰れないエンジニアの1日 プログラムを書く ↓ 実行 ↓ うまく動く ↓ 急なタスクを言い渡される ↓ 引き続きプログラムを書く ↓ 焦りによるイージーミス ↓ 実行 ↓ コンソールが$\color{red}{\rm 真っ赤なエラー}$を吐く ↓ 引き続きプログラムを書く ↓ 焦りと苛立ちによるイージーミス ↓ 実行 ↓ コンソールが$\color{red}{\rm 真っ赤なエラー}$を吐く ↓ 追加で急なタスクを言い渡される ↓ 引き続きプログラムを書く ↓ 焦りと苛立ちと強迫観念に

「ある冬の日、俺は運命と出会った」 （注）この記事はカレシ・カノジョできないエンジニア Advent Calendar 2016の20日目の記事です。 初投稿ですが生暖かい目で見てください。 なぜ書こうと思ったのか 「冴えない彼女の育て方」というアニメを見て加藤恵LOVEになった 加藤恵のような彼女が欲しい ということで、彼女を造ろうと思います。 別にクリスマスが近いから彼女が欲しいとか、そういうわけでは（ｒｙ もちろんタイトルは「冴えない彼女の育て方」から来ています。 なにするの？ 興味本位でhubotとchatworkを連携させてみたので、それのメモ書きとして 「chatworkで送信したメッセージに対して特定のメッセージを返信する」 というbot彼女を作成します。 大きな流れとしては 必要なものをインストール hubotとchatworkの連携 彼女の作成 いちゃいちゃ となります。

最近新卒の面倒を見始めた中堅エンジニアが 意識していることを大雑把にまとめてみた。 こういう記事を書くのはあまり慣れていないので、 生暖かく読んでください 失敗から学び、繰り返さないようにする テスト環境で失敗を繰り返させる 本番環境でミスの発生率を下げる 失敗したら以下を本人に確認する ↓ どうしてミスが発生したか 再発防止策はどうするか 同じミスを周りの人が起こさないにはどうするか ↓ 原因をしっかり自覚させる 同じミスをしないように対策を一緒に考える 翌日チームに共有させる 必要に応じて社内向けの技術記事も書かせる 使う側のことを考えて仕事に責任感を持たせる ある程度物が作れたらまずは自分で使わせてみる 他の人からも意見をもらう 過去のクレームやご意見を見させる ↓ 自分の作業に責任感を持たせる 仕様が本当に適切か常に考えさせる 製品がさらに良くなる提案をさせる コードレビュー 早い

この投稿は カノジョできないエンジニア Advent Calendar 2016 の 6日目の記事です。 ※ ピンチヒッターで投稿させて頂きました。 質問 突然ですが皆さん、このようなサイトをご覧になられたことはないでしょうか。 そうです。技術系ブログの Developers.IO です。 技術的な質問を Google先生にぶつけるとこちらに案内される事も多く、普段からとてもお世話になっております。 こちらは クラスメソッド株式会社 様が運用されているブログなのですが ある時・・このブログに女神が舞い降りました。そう、めそ子さんです。 めそ子さん あぁ女神・・ お馴染みのジョインしました記事や専用コーナーがあるので詳しくは書きませんが、簡単にご紹介を。 2016年7月7日にブログに舞い降りる 趣味はメガネ収集 好きな寿司ネタはサーモン 詳しくは -> クラスメソッドにJOINしました『めそ

PhalconについてくるVoltについて俺的めも Voltテンプレート PHPの関数とかをテンプレートで使いたいことがよくあるけど http://phalcon-docs-ja.readthedocs.io/ja/latest/reference/volt.html#id4 Voltではここで定義されてるのしか利用できない。 以下のようにaddFunctionしてやると使えるようになる。 $di->set('view', function () use($di) { $view = new View(); $view->setViewsDir(__DIR__ . '/views/'); $view->registerEngines(array( '.volt' => function ($view, $di) { $volt = new View\Engine\Volt($view, $