タグ

ブックマーク / yyyank.blogspot.com (9)

  • ベテランになるほどブログを書かなくなってくる

    ‌ という完全に仮説というか思考実験みたいなものを書いてみます。 ざっくりまとめ ベテランの何気ない情報は世に出にくいという仮設 ベテランは、独自見解など良い感じのもの以外の簡単な技術記事が書けなくなる、書きにくくなる 簡単な記事は経験浅めの人に偏りベテランは簡単な記事を書かない。簡単なものでも書いてくれるベテランは、アウトプット好きに限られる 簡単なものであったとしても世に出してくれれば嬉しいな 前提 経験の浅い人 = 初級者 ベテラン = 中級者以上 とおきかえてもらっても良いかもしれません。 経験の浅い人は簡単なことでも感動できるのでブログを抵抗なく書きやすい 例えば 「Javaのセットアップが出来た!」 「Rubyのセットアップが出来た!」 「このライブラリで良い感じに出来た!」 はじめのうちは一つ一つが嬉しいし一つ一つにハマりがちだったりするので、 感動もありハマりどころもありブ

    ベテランになるほどブログを書かなくなってくる
    peketamin
    peketamin 2023/05/22
  • クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)

    すでに何人かの人がクリーンアーキテクチャなんてないよ、って話はしていてイマサラだと思うんですが。 あえてブログの記事に残そうかなと思って書いてみます。 最近、改めてクリーンアーキテクチャを読んだり、原文を読んだり、 ここ数ヶ月ツイート色々な人のを観測したり社内で話したりしていて 考えがまとまってきたので、自分の言葉で整理してみたくなった。 「へー、クリーンアーキテクチャっていうソフトウェアアーキテクチャがあるんだー」という微妙な誤解?をちょっとでも減らす一助になればという感じです。あと、の読み進め方のヒントにもなるかも 先に結論 クリーンアーキテクチャというのはアンクルボブの書いた。 ソフトウェアアーキテクチャのことではない。 the クリーンアーキテクチャというブログ記事はただのソフトウェアアーキテクチャの例(そしての一部分)だが、独り歩きしている クリーンアーキテクチャというソ

    クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)
    peketamin
    peketamin 2021/09/03
    わかる〜
  • 主にターミナルですごすための個人的開発環境

    モチベーション ターミナルからなるべく色んなことやりたい。動きたくない。冬のこたつみたいな感じ。 前提 MacとArchでだいたい似たような環境が作れたので対象OSはそのあたりです。 まえがき 色々情報交換や情報収拾するうちに 少しずつ自分の開発環境が変わってきたので現時点のスナップショットとして書いてみたくなった。 dotfileの延長でしかないため自分の秘伝のタレであり、自己満感が強い。 他人の参考になるかは分からないけど、なれば幸い。 逆にこういう記事書くと教えてもらえたりしないかな(打算) とどのつまり? https://github.com/yyYank/dotfiles あたり。 iceberg tmux zsh zsh-autosuggestions zsh-syntax-highlighting zsh-completions zsh-history-substring-s

    主にターミナルですごすための個人的開発環境
    peketamin
    peketamin 2020/07/07
  • 個人的なメモの色々(scrapbox、trello、hugo、Googleカレンダー、mattn/memo)

    個人的なメモの色々(scrapbox、trello、hugoGoogleカレンダー、mattn/memo) 最近いろんなドキュメントというかメモというか。雑文の置き場所を考えている。 trello scrapbox hugo(github.io) Googleカレンダー mattn/memo などに最近は落ち着いてきたかなと思う。 なんでこんな色々つかってんの?っていう自分なりの理由についてのお話です! どこに公開して誰に見せるか見せないか このブログの内容も大体雑多なものなんだけど、 一応このブログに書くならこういう書き方、こういう内容みたいなものが自分にはある。 なので、全て日常なりなんなりをこのブログにだけに書くわけにもいかない。 そういった中「書きたい内容ごとにツールを分ける」必要性を感じてきた。 そこで、今回は何をどういう意図で使っているかを書いてみます。 trello ここ数

    個人的なメモの色々(scrapbox、trello、hugo、Googleカレンダー、mattn/memo)
    peketamin
    peketamin 2020/04/10
  • 【そんなBigDecimalで大丈夫か】Javaシステムの計算処理について

    Twitterの話題に乗っかって、内容をまとめてみようと思います。 私自身の考えではなく、様々な意見を整理したいなという試みです。僕には知識はありません。 B○zzNews並みに頑張ろうと思います。 前提 基的に、Javaを中心として、その周辺についても少し触れるぐらいのアプローチで書こうと思います。 ポイントとしては、以下の3点です。 ※無意識に利用している部分(基礎的で普段意識しないところ)ではありますが、とても重要な話です。 1.Javaではあたり前のように計算処理にはBigDecimalが使われている 2.ではなぜ、BigDecimalではないといけないのか 3.どういった計算ならBigDecimalを利用するのか/利用しないのか ※記事は演算誤差についてあまり厳密に的確な内容ではない可能性があります。 Java内の演算処理方法としてベターな方向の提示を目的としていますが、「誤

    【そんなBigDecimalで大丈夫か】Javaシステムの計算処理について
    peketamin
    peketamin 2017/09/05
  • 【Java】定数クラスをどうしたものかと改めて考える

    いや、大した話じゃないんですけど みんなどうしてるのかなって思って。 Javaの定数クラス。皆さんの使用状況はこんな感じだろうか。 なにそれ? 知ってるけど使ってない 全部propertiesファイルとかxmlとかに持ってるから使わない 使ってる 使うとすればどのように使うのが良いかなとか。 わざわざ考えたりしないような気がするので、あえて考える。 定数クラスとは 定数クラスとはpublic static finalなフィールドをたくさん持つクラスで、 定数を管理するために用いられる感じ。 ざっくりとこんなの。 見たことある人は「あー、、。。。」となる。 public final class Constants { public static final String SLASH = "/"; public static final String BLANK = " "; public s

    【Java】定数クラスをどうしたものかと改めて考える
    peketamin
    peketamin 2017/07/10
  • チケット管理のアンチパターンとベストプラクティス

    主語がでかいタイトルですが、自分なりに考えようという目的です。 自分の思考の整理。 何か意見があればガンガンコメントなりツイートなりして欲しい。 前提として、 チケット管理システムは2つぐらいしか使ったことがないので、そちらに偏ってしまうかも。 ちなみにRedmineとBacklog。 (今がRedmineだから多分それに偏る気が) アンチパターン アンチパターンというのかは分からないけど 今まで困ったこと、やりにくいと感じたこと、ダメだこりゃ、と思ったこと。 ・運用フローが複雑 フローが複雑だと途端に人は面倒になる。なるべく抜け道を探し秩序が乱れる。 抜け道が見つかると割れ窓理論とかいうやつで、どんどんぐちゃぐちゃになる。 誰もフローに乗ってくれない状態になる。 ・使われていない項目がある なぜあるのかわからない項目。重要そうだけど埋めなくても良い項目。 誰かが埋めてくれるだろう、他の人

    チケット管理のアンチパターンとベストプラクティス
    peketamin
    peketamin 2016/02/24
  • SIer to SIer

    6月30日をもって、SIerのちっちゃい会社を辞めました。 7月からはSIerのちっちゃい会社で働きます。 僕が強く主張したいのは、転職タイミング的に夏のボーナスが出ないということです。 皆様のご好意をお待ちしてます!!!切実にビールとか技術書とか!! ほしい物リスト なんでやめたの? 特に会社に大きな不満はありませんでした。 それに技術者のはしくれとして飯をっていけるようになったのは この会社のおかげなのでそこは頭上がりません。 ただ、この会社でやりたいことは全てやったなという 自分の中でのしきい値を超えただけです。 客観的に見てやり尽くしたわけではないでしょうが、 僕個人の主観としてはもうこれ以上はやることないなと。 1年前ぐらいの段階でその結論には至ってて、 あとは環境面、待遇面、業務内容などで良い会社 と巡り合えればなぁという気持ちでした。 これから何やるの? これからも基的に

    SIer to SIer
    peketamin
    peketamin 2015/07/01
  • 泥沼プロジェクト振り返り

    はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない

    泥沼プロジェクト振り返り
    peketamin
    peketamin 2015/04/17
  • 1