やばい、iOSにネイティブアプリ要らなくなるかも。SafariもPWAに対応する可能性 - Qiita
これ以上は長くなるため後述． Chromeは既に，Safariもようやく 上記の通り，Service WorkersがPWAでも最重要な機能の一つである．Chromeでは既に対応済み． しかしSafariが対応しておらず，世間的にはモチベーションの上がらない状況であった（やちまもその一人である）． Safariにおいて，Service Workersの実装状況 No active development が Under Consideration になったのは2015/12/041のことである． 20ヶ月という永遠とも呼べる時を経て，2017/08/032にようやく In Development となったわけであった． ちなみにMicrosoft Edgeでは既に開発中34である． だから何なのか SafariにService Workersの実装がなされると，一気にウェブアプリへの移行が
「PictRuby」iOS用のプログラミング言語Rubyが面白い
実用的に使えるiOS用のRuby iOSで動くプログラミング言語Ruby、PictRubyがリリースされていました。 PictRubyは、iOS 8.0以降。iPhone、iPad、およびiPod touchに対応した、オープンソースのユニバーサルアプリ。 組み込み向けのRubyであるmrubyを内蔵しており、ネットワーク環境不要でRubyスクリプトが実行可能。 PictRuby カテゴリ: Productivity 販売元: Tomokazu Tsuruoka（サイズ: 1.6 MB） 全てのバージョンの評価: （0 件の評価） このPictRubyはテキストエディタ、ファイル管理機能、実行環境が備わった簡易IDE。Rubyスクリプトを作り、編集し、そして実行できます。 当初、画像処理に特化した形でリリースされましたが、後にバージョンアップでiOSのクリップボードを扱えるようになり、テキ
ソフトウェアの開発にかかる時間の見積を廃止したいプログラマーたち | スラド デベロッパー
ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。 記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事
【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ～「テスト」という工程が必要な理由 | きのこる庭
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
発注者「簡単なアプリです」エンジニア「簡単か否かを決めるのはお前じゃない」
発注者「誰かiPhoneアプリ作ってくれませんか？簡単なアプリです！！」 エンジニア「簡単かどうかを決めるのはお前じゃない。」 — のり@食べるの大好きエンジニア (@sugi511) 2014, 11月 10 発注側と受注エンジニア側だけでなく、同一社内の営業と開発という部門間でも生じやすいギャップのお話。はた目にはシンプルそうに見える、ちまたに沢山出回っているから簡便そうに見える、だから作るのも簡単だろう。作ってくれませんかと発注側は語るけれど、実のところ開発が簡単か否かを決めるのは発注側では無くて開発側。 数枚、あるいは数行の仕様での発注案件でも、いざ開発してみると山ほどのリソースを投入して数か月かけても終わらないという事案も山ほどある。プログラム、アプリ開発周りで分かりにくければ、料理などが分かりやすいかな。シンプルに見えるけど目新しくて美味しい料理。そこにたどり着くまでにどれほど
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
時間をかけて、つまらないものを作りたいか？ - futoase
時間をかける つまらない想像話を以下に書く。 失敗してはいけない。成功しなければ行けないプロダクトだ。 企画から色々と実装アイディア、目的とするユーザー像を聞いている。 それに見合ったシステムを実装しなければならない。 あと6ヶ月で。その間は徹底的に企画と話をする。 部長と話しをして、駄目だったら作りなおす。 6ヶ月の間、エクセル上にガントチャートを引き、開発スケジュールを引いた。 企画・営業は2名。そのうち1名はマネージャ的な担当を行う。 部長は最終決定を下す(と聞かされている)。 エンジニアは3名。チームとしてはまあ良いほうだろう。 3ヶ月後 何を作っているのかわからなくなってきた。 具体像もわからない。 エクセルに書いたガントチャートは、意味を成していない。 ガントチャートを直そうと思うと、他の予定もずらさなければいけなくなり、 だるくなってだれも更新しようとしない。 システム全体の
Microsoftに捧ぐ
理論的にはソフトウェアが壊れるということはない。長く使っているうちにビットがすり減ってしまうということはあり得ない。何かがうまく動かないのは、はじめから壊れていたのだ。それにも関わらず、世界中のプログラマが、ソフトウェアが壊れていくさまを目撃する。昨日までうまく動いていたものが、今日はコアを吐く。 バグを見つけたら修正しなければならない。しかし、そのバグフィックス自体が、新たなバグを持ち込む可能性がある。したがって、ソフトウェアにはメンテナンスが必要である。このメンテナンスには終わりはない。ソフトウェアは「リリースしたら終わり」の製品ではない。 ソフトウェアベンダーは植木屋と同じである。植木屋は、植木を「リリースしたら終わり」ではない。何十年、ときには何百年も成長し続けるという植物の性質上、植木にも終わりのないメンテナンスが必要である。この点では、日本の植木職人もヨーロッパの庭師も同じであ
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
RubyMotion Tutorial: Ruby で iOS アプリを作ろう
RubyMotion TutorialRuby で iOS アプリを作ろう by Clay Allsopp Follow @clayallsopp 日本語訳: RubyMotion JP RubyMotion を使うと Ruby で iOS のアプリを開発することができます。これまで Apple のプラットフォームにおけるソフトウェアは Objective-C という、素晴らしいがその一方でニッチな言語しか使用できないよう制限されてきました。RubyMotion は完全にネイティブで、効率の良い他の言語による開発を可能にします。その言語とは Ruby です。 RubyMotion Tutorial では iOS SDK をできる限り Ruby らしく使うために必要不可欠なトピックを学ぶことができます。すべてを網羅はしていませんが、洗練されたアプリケーションを最大限素早く開発するための道しる
ソフトを他人に作らせる日本、自分で作る米国：日経ビジネスオンライン
物事に大きな影響を与える前提なのに案外知られていない。その一つがコンピュータソフトウエア投資とソフト開発技術者の所属先に関する日米の差である。 日本企業は自社で利用するソフトのほとんどをIT（情報技術）企業に開発させているのに対し、米国企業はソフトを内製する比率が高い。 日本のソフト開発技術者の大半はIT企業に所属するが、米国のソフト開発技術者の大半はIT企業ではなく一般企業に所属している。 上記二つの文は同じことを言っている。日本企業は社内にソフト開発技術者をあまり抱えていないためIT企業に外注するが、米国企業は社内にソフト開発技術者がおり内製できる。 「ほとんど」「高い」「大半」では曖昧なので数字を補足する。米国商務省経済分析局の数字によると、2010年の米国民間企業におけるソフトウエア投資の内訳は、内製（自社開発）が37.3％、外注（他社委託）が34.2％、パッケージソフト購入が28
Apple、誰でもアプリを作れるツールを開発か | ブログヘラルド
優れたアプリを作るのはプログラマーだけであるべきだと誰が決めたのだろうか？iOSのアプリをWYSIWYGのワードの文書と同じぐらい簡単に作れたらどうだろうか？新しいアップルの特許出願の書類には、まさにこのアイデア - 非常に明確であり、且つ最高のアイデア - を描写しており、何もかもを変えるポテンシャルを秘めている。 アップルは昨年の12月に新たに「デバイスのプラットフォーム用のコンテンツの設定」と言う名の特許を申請していた（アップルインサイダーによってこの特許の存在が明らかにされたのは今週だが）。これはアプリを作る人のためのグラフィックUIツールである。アップルがこの特許の技術を実現すると、- プログラマだけでなく - 誰でも自分のアプリを作り、アップストアで販売することが出来るようになる。 今年の年明け、アップルはiブックオーサーを無料でリリースし、インタラクティブなeブックのメーカー
「はてな教科書」をgithub上に公開しました - Hatena Developer Blog
こんにちは、id:shiba_yu36です。 はてなのエンジニア陣によって執筆されたウェブアプリケーション作成の基本を学ぶための「はてな教科書」をgithub上に公開しましたのでお知らせします。 はてな教科書は、はてなサマーインターンでも利用されている、約1週間でウェブアプリケーションの基本を身に付けるためのものです。はてなでは日々のウェブ開発で得られたノウハウをこの教科書を継続的に盛り込みながら、インターンシップやエンジニアの新人教育などに利用しています。今回、はてな教科書をgithub上で公開することで、広くPerlを使ったウェブアプリケーション開発に興味を持ってもらえれば、と思います。 いまのところ公開されている資料は、以下の4つになります。 Perl によるオブジェクト指向プログラミング ORM によるデータベース操作 (DBIx::MoCo を使った開発) MVC によるウェブア
開発プロセスとしての伽藍とバザール - yojikのlog
わかりやすく、21世紀現在の言葉で、伽藍とバザールという対比を現実社会に当てはめると、もっとも近いものは、ウォーターフォールvsアジャイル だ。 artonさんが述べているように、伽藍とバザールは、OSSのアジテーション文書とかハッカー賛美の書ではなく、実際にはESRがFetchMailの開発をすることによって得たバザール方式開発プロセス*1のプラクティスを紹介するエッセイです。 コードをオープンにすることは必要条件であって十分条件ではない。コードをオープンにすることは、それ自体が目的じゃなくて素敵なソフトウェアを自然につくるための手段にすぎない*2。一般的な開発者の数百倍の生産性をたたき出すハッカー賛美などはどこにも無い。 いくつか興味深い部分をピックアップしてみましょう。 6. ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。 これは、XPな
新社会人の君へ-disるということについて - あんちべ！
「ご趣味は？」と聞かれて「Lispをdisることですね（ｷﾘｯ」と答えてしまい、 合コン開始4秒で蚊帳の外に放り出されるあんちべです、こんばんは。 今から長い文章を書く。 結論だけさっさと言っちゃうと 「まぁ、初めのうちは、あんまり『○○は使えない』とかdisらない方が良いよ」の一言だ。 さぁ、それで話しはおしまい。もし暇だったら続きも読んで欲しい。 （あと、この文章はたった一人のために書いた。 ちょっと妙に聞こえるところもあるだろうけど、そこは聞き流して欲しい） 私はよくいろんなものを嫌いだ嫌いだとdisる。 にわかベイジアンが嫌い（話すと長くなる）、Javaが嫌い（JVMは愛してる）、Perlが嫌い、 MavenとかCVSとかが嫌い、アジャイルアジャイル言ってる人が嫌い（アジャイルが嫌いなわけじゃないよ）… 言い出したらキリがない！毎日新しいdisりの種が沸いてくるんだ！ 何度か様々な
アドビの新ツール「Shadow」は、モバイル用Webアプリ開発者必須のツール
モバイルデバイス用のWebサイトやWebアプリケーション開発で大変なものの1つが動作確認です。何台ものデバイスを机の上に並べて、ひとつひとつ確認しなければなりません。 アドビシステムズのAdobe Labsが公開した「Adobe Shadow」は、そうした苦労をしているデベロッパー、デザイナーにとって手放せないツールになるでしょう。 複数デバイスに対する同時表示とリモートインスペクション Shadowがどんなツールなのか解説用ビデオの説明を紹介しましょう。 iPhoneアプリのShadowを起動すると番号が表示されます。 その番号を、MacOSかWindows用Chromeブラウザのエクステンションとして配布されているShadowに入力します。これで、ChromeブラウザとiPhoneがペアになりました。 同じように、Android用ShadowもChromeブラウザとペアにすることができ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
英語で何だったっけ？再現方法、根本原因、回避策、、、 - Qiita
AppStore申請を一式まるっと自動化する
Situs Judi Online dan Slot Online Bocoran Rtp Terpercaya Indonesia - devtoolstips.com
特許庁システム開発中断:東芝子会社など２社５６億円返還 - 毎日新聞