大手SIerの現状 ソフトウェアはハードウェアの付属品だった 下克上が始まる もう一度ソフトウェア技術者を社内に引き込む 最後に 今日は、ちょっと真面目な話。 昨日の夜にふと、あるブロガーさんの記事を見た。 blog.net-li.com この方は、実際にシステムを発注する側での意見を書いておられた。 簡単に説明すると、今まで委託していたIT会社が親会社に吸収合併されることにより、人件費が親会社の基準に移行され、発注額が変わるというものだ。それに対して、「ちょっと待ってくれよ・・・」って言う意見。 確かに。私もそれには全面的に肯定する。ユーザ側から見ると、勝手な価格変更になってしまう。今までのサポート体制と変わらないのに金額だけが上がるからだ。理不尽だ。それも分かる。 今回は、技術屋としての意見を少し話させていただきたい。少しだけ聞いて欲しい。 大手SIerの現状 今から言うことは、あくま
個人でやってるWEBメディアが300万くらい使ってるんですけど、それを続けていく理由をこっちで書きます。 元記事: https://note.mu/isay53/n/nf94c76c4e6bf 元記事で書かなかったのは、読む層が違うんじゃないかなと思ったからです。 【1】好きなことで競合がいなくてやらないと勿体ないと思いました これは最初のきっかけ的な部分です。コーヒーのメディアは先駆者がいませんでした。今時思いついた物がまだ存在しないって凄まじく貴重なので、それだけでもう作らないと勿体ないと思います。採算も無視しても色々なメリットが後から付いてくるんじゃないかと思います。しかも自分の好きなジャンルなんだから奇跡だと思ってます。この事業をやりたいと思ったのでその気持ちを大切にしています。 そもそも前の記事で書いたんですが、石原さとみレベルの成長率なのでないことに気づいて作らないのは勿体ない
スタートアップの採用基準 玉木諒氏(以下、玉木):渡邉さんは、人・チーム関連で、「ちょっとこれ、やっちゃったな」みたいなことはありますか? ピボットの際とかも含めて、どうでしたか? 渡邉拓氏(以下、渡邉):人関連は、幸いあんまりなくて。入れる人もかなり精査しますし。前に別の事業をやってたんですけれども、その時も、しっかり方向性が定まるまで人を入れなかったり。人に関してはないですね。 権限委譲の話があったかと思うんですけれども、新規事業を任せるだとか、営業トークを任せるだとか、開発任せるだとか、いろいろ出てくるなかで、基本的には、自分に全部責任があると思っているので、自分自身でセーフティネットを張るという考え方で、事業を全部見てるんです。 任せてはいるんですけど、例えば、メンバーがメールを返してないとか、そういうのも全部見てます。開発とかも進捗が遅れてると、それが人のリソースが足りないのが原
RxSwift勉強会 @ Sansanの発表資料です http://connpass.com/event/27933/
Rxで、処理の実行スケジューラーを切り替えるオペレーターとして、 subscribeOn と observeOn があります。 この2つは雰囲気がよく似ているので、ドキュメントを読んだ時点では今ひとつ違いが理解できなかったのですが、コードを書いて実行することで、その差が明確になりました。 どちらも使わない場合 次のコードを実行してみます。 const observable1 = Rx.Observable.create(observer => { console.log("[A] before onNext(1)"); // (2) observer.onNext(1); console.log("[A] after onNext(1)"); // (4) console.log("[B] before onNext(2)"); // (5) observer.onNext(2); con
using System; using System.Reactive.Concurrency; using System.Reactive.Linq; using System.Threading; namespace TestSpace { class Program { static void Main( string[] args ) { Console.WriteLine( $"Main:{Thread.CurrentThread.ManagedThreadId}" ); var sequence = Observable.Create<int>( o => { Console.WriteLine( $"Create:{Thread.CurrentThread.ManagedThreadId}" ); o.OnNext( 1 ); o.OnNext( 2 ); o.OnCompl
RxJava Advent Calendar 2015 の 12月12日分です。 RxJavaのSchedulersは、RxJavaのコールバックの実行スレッドを制御するためのコンポーネントです。 恥ずかしながら、最近まで subscribeOn() と observeOn() の使い方を理解していませんでした。よって本稿では、 subscribeOn() と observeOn() の現状の私の理解したところを書きます。 SchedulersとsubscribeOn() / observeOn() RxJavaのSchedulersまわり一番難しいのは subscribeOn() と observeOn() がどう違うのか、という点だと思います。 これは実用的には以下のように考えるとよいかと思います。 subscribeOn() は Observable.OnSubscribe#call
高瀬です。 今回はAndroidアプリを作ってみる。目指すものは、Webサーバからデータを取得し、それを画面に表示する、という機能の実現とする。 アプリとWebサーバとの通信はRESTの形で行う。アプリ側でのRESTの実装にはSpring for Androidを利用。このSpring for Androidを試してみることが本題なのだが、RESTのサーバを準備したり、JUnitでAndroidアプリのテストなどもやってみる。 ソースコードはGitHubのandrestリポジトリを参照。 RESTについて 自分はRESTが何なのか分かっていないので、まず用語辞典を読んでみる。 RESTとは http://e-words.jp/w/REST.html やっぱり何だかよく分からないが、自分の認識を書くと以下のとおり。 URLが一つのリソースを表す。 リソースへの操作の種類をHTTPメソッド(G
電通の新入社員だった女性が入社1年目の12月に自殺したことを受け、月105時間の残業時間もあったことなどから労災と認定されました。彼女の冥福を心からお祈りいたします。当件について私はまったく知らないため、これ以上の言及を避けたいと思いますが、ここでは大手広告代理店の若手社員にとっては避けて通れない「長時間労働」について書いてみます。 私は1997年4月に業界2位・博報堂に入り、2001年3月に退社しました。以後、フリーのライター・編集者・PRプランナーとして働いてきましたが、これまでに最も働いたのはどう考えても会社員時代だったと断言できます。フリーの方が悶絶するようなブラック労働をすると思われるかもしれませんが、間違いなく会社員時代の方が長い。今回は電通の方が自殺するという事態になりましたが、若者の長時間労働においては似たような面があり、これは広告業界の悪習ともいえるものです。 なぜ、そん
以前、Gitの使い方、よく使うGitコマンド という記事を書きましたが、git rebase -i の項目に書き足したいことが増えてきたので別エントリに切り出し、内容を見直しました。 git rebase -i を使うと、最新のコミットから指定したコミットまでの歴史を対話式に改変することができます。具体的には以下のことができます。 コミットメッセージを変更するコミット内容を修正するコミットを分割するコミットをまとめるコミットを削除する 私個人の利用シーンとしては、開発ブランチを master にマージする前(プルリクを送る前)にコミットの整理に使うことが多いです。一発できれいなコミット履歴を作るのは難しいので、散らかったコミットを後から整理するのによく使います。Git って便利だなあと思う瞬間です。 目次 rebase -i の使い方 reword コミットメッセージを変更する edit
はじめに ※ 以前git rebase -i して何か失敗して痛い目にあったりした ※ これ。git rebase master に失敗した模様のとき【git】 ※ でも最近ちゃんとgitを理解し出したので再挑戦したらgit rebase -i がやっぱりイケてる 前提 ※ .zshrc (.bash_profile?) にて、gitのデフォルトエディタを設定しときます .zshrc export GIT_EDITOR=vim ※ あと、念のためローカルbranchは新しく切って試します % git branch * develop master % git branch rebase_test % git branch rebase_test * develop master % git checkout rebase_test ※ ぜんぜん関係無いけど、tigあるとちょっと幸せかも そ
こんにちは、エンジニアの王です。今回は、Git初心者を悩ませるリベースについて解説してみたいと思います。 リベースが初耳 リベースを聞いたことはあるけど、使っていない 不安を抱えながらも、リベースをなんとなく使っている 上記に当てはまる方は、ぜひ読んでくださいね。 リベースで何ができる? コミットが綺麗になる! 以上です! この一言に尽きる! 具体的にどのように綺麗になるかというと…… コミット履歴がわかりやすくなる コミットメッセージを後から変える コミットの順序を後から変える 2つ以上のコミットを1個に統合する 一度コミットした内容を編集する といった具合でしょうか? 整理整頓が好きな方は、ぜひリベースを使いこなしていただきたいと思います! マージとリベース 2つのブランチの変更点を統合するとき、Gitの最も一般的なやり方は、マージとリベースを使うことです。マージは初回で説明したので、
Androidアプリで、画面からなにか処理した時に 外部のWeb APIから情報を取得(http getリクエスト)するロジックを書いていたのですが、 なぜかリクエスト投げるとNetworkOnMainThreadExceptionというエラーが返ってくる。。 調べてみると、どうやらAndroid3.0以上では メインスレッドからネットワーク処理を行うことを許していないらしい。 確かにエラーが出たときはAndroid4.?でデバッグしてました。 と、いうわけで 「AsyncTask」を使って別スレッドでhttpリクエストを投げることにしました。 〜大変参考になりました!〜 ・android開発|「AsyncTask」利用:android.os.NetworkOnMainThreadExceptionエラーへの対応方法 — 検索プログラマのメモ帳 ・AsyncTaskを使った非同期処理のきほ
はじめに RxとRetrofitを組み合わせて使われることが多ですが、初見だと一体何をしているのか全くわからなかった覚えがあります。 なのでRetrofitの基本的な使い方を書いて、Rxを組み合わせて使うところまで書ければと思います。 今回使うretrofitはver.1.9.0です。 ミニマムの実装 retrofitでやることは主に以下の4点です。 インターフェースを定義する Entityを用意する(下のコードではWetherResponseクラス。このブログの最後に今回使ったサンプルを貼っています) 定義したインターフェイスの実装を取得する(下のコードではMainActivityの5行目) コールバック内に処理を記述する compile 'com.squareup.retrofit:retrofit:1.9.0' public interface IWhetherApi { @GET(
RxJavaはObserverパターンの拡張です.ObserverパターンはGoFのデザインパターンにも登場するほど非常に一般的なものです.「オブジェクトの状態変化をそれに依存する他のオブジェクトたちが監視し,通知があったら各自が自動的に適切な振る舞いをしてほしい」というのが基本的なアイディアです.Javaではこれをinterfaceを使って実現します. 関心がある状態変化イベントをもつ対象をObservableと呼び,そのイベントを監視する対象をObserverと呼びます.java.utilパッケージにもObserverインターフェースとObservableクラスがあります. java.util.Observerインターフェースはupdate()メソッドを定義しています.状態変化を知りたい対象にはObserverインターフェースを実装してObservableに登録しておきます.そして,状
はじめに リアクティブプログラミングでアプリを設計するにはどうすればいいんでしょうか?できるだけ直感的に理解できるようにビジュアル化して解説します。 今まで RxSwift についての以下の記事を書いてきました。 オブザーバーパターンから始めるRxSwift入門 RxSwift入門(2) 非同期処理してみる RxSwiftを深く理解する RxSwiftの機能カタログ まずは既存のイベント通知のやり方を置き換えたり、非同期処理に使ったり、「すぐ使える便利な道具」として RxSwift を使ってもらおうという趣旨で解説しています。 そのため「リアクティブプログラミングとは?」とか「関数型としての側面が〜」とか、オブジェクト指向プログラマにとって敷居が高そうと感じられてしまう言葉や説明を避けてきました。 概念よりもまずライブラリとして使って親しんでからの方が、概念も理解しやすいと思ったのです。R
一番最新のやつはこっち rei19.hatenablog.com 前提 新しいトライとしてAndroidを書き始めてだいたい半年くらいたったのですが、教科書通りにコードを書いていたもののAPIを呼ぶあたりの実装がどうにもしっくりこなくかったので、良い機会だと思い設計を見直す事にしました。 以下、めっちゃ参考にしたスライド。ありがたや。 iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い from Ken Morishita iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い ポイント 基本的にModelは死なない + 通知で変更を伝える役割を持つ ViewやVCでAPIを呼ぶのはユーザーの操作に影響されやすいからやめれ 作ってみた 以前、このポストでAtndのAPIを呼んで結果をListViewに表示してみるというのを勉強のア
2016年10月7日、三田労働基準監督署は元電通社員 高橋まつりさん(享年24歳)の自殺について、これを過労死と認定した。 24歳東大卒女性社員が過労死 電通勤務「1日2時間しか寝れない」 クリスマスに投身自殺 労基署が認定 電通は過去にも社員の過労死事件を起こしており、2000年まで遺族との係争を続けていた。今回の事件はその反省が活かされることなく、同じ悲劇が繰り返されてしまったという形になる。ちなみに、前回の被害者も今回と同じ24歳。新卒一年目での自殺…というのも同じパターンだ。 【事例紹介】1991年 電通の過労自殺事件を紹介します。 今回の過労自殺事件が過去の事例と異なり興味深い点は、SNSによる被害の可視化が可能になっていることだ。上の朝日新聞の報道にもあるように、高橋まつりさんはtwitterアカウントを持っており、友人や家族に向けてひんぱんに「つぶやき」を投稿していた。 その
楽に開発するためにAndroid全体の設計をしたいという思いは、わりとどの開発者も持っている気持ちだと思う。 設計というのは昔から色々揉まれてきて、今はMVPだMVVMだ、DDDだと盛り上がっている。 そもそも、Androidというフレームワークに限定された環境で、わりとよくある実装が多い中で、未だにこれだけたくさんの人が困っているという状態がおかしい。おかしすぎる。そろそろAndroidでこういうの作りたいならこう作るでしょ、みたいなベストプラクティスが確立しているべきじゃないのかという気がする。 あくまで個人的にはだけれども、DataBindingが主流になるのであれば双方向バインディングを使ったMVVMが一番しっくり来る。ただ、MVVMだとViewModelが太ってきてどうすんのみたいなことになるかもしれない。また、通信やキャッシュ部分は別のクラスにわけようとかそういう指針はどちらに
Introduction Retrofit turns your HTTP API into a Java interface. public interface GitHubService { @GET("users/{user}/repos") Call<List<Repo>> listRepos(@Path("user") String user); } The Retrofit class generates an implementation of the GitHubService interface. Retrofit retrofit = new Retrofit.Builder() .baseUrl("https://api.github.com/") .build(); GitHubService service = retrofit.create(GitHubServ
あんまり言及されないが、Androidは65K問題とかあるので気にしたい点。 jacksonは早いのだけれど、10Kのmethod数を持っていかれるのでデカいアプリやGooglePlayServicesを利用するアプリは注意しておいたほうがいい。 JSONのfield存在チェック 例えば {"hoge":"fuga"} ってjsonが来た時に {"piyo":""}ってfieldが存在することを保証したい。 これを例外として扱う仕組みをライブラリ側でサポートしてるかどうか Gson Gson optional and required fields できるにはできるがクラスごとにDeserializerを設定しなくちゃならないのがツライところ Jackson Jackson 2.6.0 から parse時のrequired fieldをチェックできるようになった。 Moshi ドキュメント
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く