人間は間違える生き物である 以下の問題を解決するヒントになる話をします: 既存のコードを誤って壊してしまうことがよくある 作業手順が多くよくミスをしてしまう 設定が正しいのかどうかよくわからないので祈りながらdeployをしている このような問題はなにを引き起こすでしょうか? たとえば、Webアプリケーションの開発においては、誤ったデータベースの変更や決済処理を正しい状態に戻すことは難しいでしょう。 また、iOSやAndroid向けのアプリケーションの開発においては、リリースしてしまったコードを消すことはできません。 ソフトウェアにはこのようなリスクに対する安全性が求められます。 そういった意味での、安全なアプリケーションとはなんでしょうか? 一般的には、安全なアプリケーションであるために、以下のような要素が必要とされると思います。 クラッシュしにくい オペレーションを間違えにくい データ
Web屋という仕事のこれから 〜Web動向からWeb屋に必要な技術を考えてみる〜 FutureSync Vol.5 で発表したスライドです。 タイトルは釣りです。前半はほぼネタです。 中身はJavaScriptで動作するデバイスは楽しいからみんなやってみたら? という内容です。Read less
概要 妻子持ちの凡人プログラマが限られた時間で行う趣味の開発について ターゲット 仕事も大事だけど家庭も大事にしたい。でも趣味の開発もしたいソフトウェア開発者さん。 元々実力が高い方はすでに実践済の内容であると思われるため、あまり参考にならないと思います。 ライブラリの作成などに関して、不慣れで、試行錯誤している段階の方向けです。 この記事をまとめる動機 業務外の限られた時間で大小さまざまなソフトウェアを作りたい。 仕事も家庭もあるので、趣味の開発のためにまとまった時間が確保できるとは限らない。 そのため、特に大きめのソフトウェアを作る機会が少なくなりがち。 現状の問題点 大きなソフトウェアを作る際に、個別の機能を別々の小さなタスクにして、 地道に開発することもできますが、開発が長引いたり間が空いたりすると 成果物に対する熱が冷める 全体の設計思想が頭から離れる などの問題が発生してしまい
私たちソニックガーデンでリモートワークを始めて早くも3年以上が過ぎ、もはや私たちにとってリモートワークは当たり前の日常になりました。 今回の記事では「リモートワークは孤独感を生む」というよく聞く意見について、私たちの経験をふまえ考えてみました。 リモートワークとクラウドソーシングは違う 多くの人が考えているリモートワークに対する大きな誤解は、「リモートワークをすると孤独感で辛くなる」というものではないでしょうか。 そして、この誤解を生み出した大きな原因は、リモートワークとクラウドソーシングを混同してしまっている点にあると、考えています。 確かに、インターネット越しに仕事の発注と受注が出来るクラウドソーシングと、物理的に離れた場所で仕事をするリモートワークの相性はバツグンです。クラウドソーシングはリモートワークがあるから実現できたのでしょう。 だからといって、リモートワークがすべてクラウドソ
2024 大賞の発表! ITエンジニアのみなさんとおすすめの本を選ぶイベント「ITエンジニア本大賞2024」の第一弾のWeb投票、第二弾のプレゼン大会が無事に終了し、プレゼン大会会場にお越しの特別ゲスト・観覧席のみなさんによる最終投票で「技術書部門大賞」、「ビジネス書部門大賞」が決定しました。また、各特別ゲストによる「特別賞」も選出しました。ご参加いただいた皆さま、ありがとうございました! 1冊ですべて身につくJavaScript入門講座 出版社:SBクリエイティブ 著者:Mana 投票した理由や感想などみなさんからのコメント 安心して失敗していい、というところと、コードの例などがわかりやすかったです! 前作の「HTMLとCSS」も購入させていただきましたが、前回も本書も初学者でも見易く、見返したくなるつくりに仕上がっていました。絵や図解でも解説されているので、近年に多いプログラマーを目指
仕事でインターン生や経験の浅い方のレビューをしたり面接を担当したりしててよく聞かれる質問が「どんなことを勉強すればいいですか?」です。 それについてちょっとポエムを書いてみようかと思います。 主に会社で一緒に働いている人やこれから一緒に働くことになりそうな方向けに書いていますので、一般論として捉えるとやや極端だったり偏っていたりするかもしれません。ポエムなので許して。 専門家であるという視点から エンジニアとして仕事をする以上、専門家 (プロ) であるという誇りと責任を常に持って欲しいと思います。 そのためにはその自信を裏付けるための知識が必要となります。 僕のいる Web やスマホアプリの業界は流行の移り変わりが激しく、新しい情報を常に追いかけ続けないとあっという間に置いていかれてしまいます。 しかしながら新しい知識を追いかけ続けるにも確固とした基本がないと、曖昧な知識の上にさらに曖昧な
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す・・・というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり
続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下本編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから(あるいは Marionette.js を使ったらから)といって自動的にお前のアプリケーションが MVC になるわけ
電車通勤の移動時間を有効活用すべく、車内でコードなりドキュメントなり(当然ながら業務のものではなく、私的なもの)を打とうかと思っているのだが、決定的な手段が見つからない。どのような方法が一番効率的なのだろうか? 椅子に座れるのであればノートPCを広げるのが最適なのだろうが、いつも使っている電車は満員電車ではないものの、座れる機会はほとんどない。スマホを使うのも考えたが、あの小さいキーボードで多くの文字を打つのは大変そうだ。 一時話題になったポメラなどの小型デバイスは良さそうだが、立って使うのには大丈夫なのだろうか。結局、手帳か小型のノート(PCではなく紙の)に手書きで断片を書き、帰宅後清書するというのが一番無難なような気もする。 電車通勤している皆さん、車内で文字を打ちたいときはどうしていますか?
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 By Brunel University under CC BY-NC-SA Shin x blog 勉強会なんてやらなくても良いという記事がちょっと注目を集めていました。かれこれ10年ぐらい勉強会を開催したり、3年前と去年には勉強会とかコミュニティの本を出したり、僕もそれなりに頭を悩ませた経験がある方かと思うので、僕なりの現在の考えをまとめてみます。勉強会に悩む人の一助になれば、と思います。 参考文献 イマドキのエンジニアの勉強事情(勉強会の種類) IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書) アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE) 自分がすごいと思っているものの存在を広めたい
Statistics Favorites 4 Downloads 0 Comments 0 Embed Views 0 Views on SlideShare 0 Total Views 0 業務系SEの末路的なお話でして — Presentation Transcript 業務系SEの今後について 消費税増税と年金問題が与える影響 2012// 株式会社ノーチラス・テクノロジーズ http://www.nautilus-technologies.com/ mailto:contact@nautilus-technologies.com Tel: 03-6712-0636 Fax: 03-6712-0664 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.NAUTILUS Proprietary &
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く