Message List
random
@berryzplus
created this channel on May 7th. This is the very beginning of the
random
channel.
Purpose:
雑談場。リプライを求めないつぶやきとか。適当に。
Monday, May 7th
joined #random along with
kobake.
Wednesday, May 23rd
Sunday, June 10th
GitHub効果かTwitterとかで外部の方とも繋がって、ある種感動を覚えています。
Monday, June 11th
会計処理がたまっていて辛い
皆クラウドに移行してくれると楽なんですけどねぇ
Tuesday, June 12th
ヤバい。早くissue上げないと、やるやる詐欺じゃん(つД`)ノ
https://qiita.com/atsushieno/items/ce31df9bd88e98eec5c4
Qiita
(今のところ前後編に分ける予定ですが、追記したり構成が変更になったりするかもしれません。予定は未定。) ---- 2016年6月に、Microsoftがlanguage server protocolという仕様を公開しました。
...
興味深い……けど簡単ではなさそうですねぇ
vimが対応出来たようだから可能は可能だと思いますけどね(´・ω・`)
あ、Gitbookだとこんなのみつけました(継続的インテグレーションまで一括でできそう
https://azu.gitbooks.io/nodefest-technical-writing/content/
文書の校正も自動化できるのでいいかも。(node必須ですが
あ、Gitbookだとこんなのみつけました(継続的インテグレーションまで一括でできそう
https://azu.gitbooks.io/nodefest-technical-writing/content/
文書の校正も自動化できるのでいいかも。(node必須ですが
あ、そもそもgitbookがnodeどっちにしろいるか。
Wednesday, June 13th
ヤルヤル詐欺かやなだけっす
Hotfix/stay in aero snap modeみたいなブランチ名でppprとばすかも。
だめじゃん。。。
キャバクラとかで開催されると行きづらい…
ま~オフ会というよりはとりあえずサクラエディタの勉強会でも開いて、ときどき参加者の中にコミッタが混じりこんでるくらいがちょうどいいかなと思ったり
GitHubコントリビュートについては実際のところIssue上げるだけでも十分な貢献だと自分は思ってます
そのIssueを上げることも人によってはやっぱり躊躇することあるにはあるので、その躊躇乗り越えてくれるだけでもかなりありがたし。
リリースノートにはコミッタだけじゃなくてIssueあげてくれた人の名前も載せようと思ってます
良いですね。貢献者。
こういうの。
ここ自分の名前載ってるんですけど、これだけでかなり嬉しいんですよ
ゲームのスタッフロールみたいなもんです
自分生息地域が関東ではないもので、東京開催だとタイミングにより難しい確率高いです。
会社の金で移動するのが一番ですね
やっと未読メール読み終わった…
Yes...orz
しばらくしたら通知落ち着くはず
通知止められるんかいっ!w
落ち着きそうならひとまずこのままでいいです。
落ち着きそうならひとまずこのままでいいです。
notificatinで未読なくなるとgood job!!って褒めてくれるのでちょっぴり嬉しい(笑)
「これ既読にしたら絶対に忘れるなー」ってやつは未読のままにしてます
(そして数か月経過)
CodeHubというのを入れてみたらめっちゃ見やすくて驚きました。なんかオススメとかあります?
あ、ここはレスを求めないチャンネルですが。
自分は主にブラウザで直接見てました
Safariだと最近のハイテンポなやり取りを追うのが辛かったです。
気になったやつだけリンククリックしてブラウザで見てました
ちなみにPR本文については文意変わりまくるレベルでめちゃくちゃいじりまくります
最近記憶力衰えてきたのかと思ってましたがそういうことでしたか。
コメントも同様。
スマホからだとわからんですが・・・
ホントだw
Thursday, June 14th
エゴサーチじゃないけどサクラエディタでググってたらサクラエディタ本が4,000円の値がついててビビる。
たしかに見やすいかも
CodeHubまちがえ。
いつの間にか人が増えてる( ̄ー ̄)
コメント内の句読点w
https://github.com/sakura-editor/sakura/pull/94
GitHub
dlg フォルダ内で単純変換して支障のないものだけを対象に変換を行いました。 手順 cd sakura_core/dlg nkf --overwrite --oc=UTF-8-BOM
.cpp nkf --overwrite --oc=UTF-8-BOM .h git checkout CDlgPluginOption.cpp git chcekout CDlgFavorite.cpp
...
何気に直してたんだというのと、あえてそこを突っ込むつっちーさんの生真面目さに吹いたのです。
あとでTips共有しときます
たかたさんに怒られた...orz
Friday, June 15th
たかたさんの話は叱られた、が正しいのかなw
> MinGW 対応が歴史的にどのタイミングで行われたのか把握していませんが、
> プロジェクトの方針としてどういう理由で MinGW に対応しようとしていたのかについて
> 経緯をご存知の方がいらっしゃいましたら教えていただきたいです。
ログ辿ったら痕跡が残ってました。
どうも2009年に公開された blog 記事を、2012年に拾って、2013年に取り込まれたようです。
元ネタは mac 上の MinGW でビルドして遊んでいただけの模様。
[upatchid:271]( https://sourceforge.net/p/sakura-editor/patchunicode/271/)
[Imp: MinGW32 コンパイル対応]( https://github.com/sakura-editor/sakura/commit/a05c87929e24f155dabdb07bad98a07e629d89aa)
なにこれ。元ネタ読んでるのに取り込んだ理由がよくわからんです。
これは怒っていい内容な気がします。
もしかして気付いてて経緯聞いてたりして・・・
GitHub
upatchid:271 Contributed by minoki git-svn-id:
https://svn.code.sf.net/p/sakura-editor/code/sakura/trunk2@2543 f7ce1907-e4c7-47ca-9f76-12c87ed2c91c
ちょっと寝て起きたけど、やっぱり好意的に書ける気がしないです。他に掲示板でのやり取りがあるのかも知れないんですが。
働きたくないでござる
@berryzplus
これ引用して Issue に貼っても良いですか?
> ログ辿ったら痕跡が残ってました。
> どうも2009年に公開された blog 記事を、2012年に拾って、2013年に取り込まれたようです。
> 元ネタは mac 上の MinGW でビルドして遊んでいただけの模様。
> [upatchid:271]( https://sourceforge.net/p/sakura-editor/patchunicode/271/)
> [Imp: MinGW32 コンパイル対応]( https://github.com/sakura-editor/sakura/commit/a05c87929e24f155dabdb07bad98a07e629d89aa)
これ引用して Issue に貼っても良いですか?
GitHub
upatchid:271 Contributed by minoki git-svn-id:
https://svn.code.sf.net/p/sakura-editor/code/sakura/trunk2@2543 f7ce1907-e4c7-47ca-9f76-12c87ed2c91c
ここまで建設的な議論はたぶん旧掲示板では無理だったと思います
google検索結果から開こうとしても開くの失敗すること多し
直近ログ追うには困らないけど昔のログ探そうとするとけっこう苦労が…
ガイドライン読んでから自重する方向が定まった感じです。完璧なprの書き方を教えるぜの日本語訳。
https://github.com/sakura-editor/sakura-editor.github.io/wiki
母数見てえええええっと思ったのは内緒の話。
母数見てえええええっと思ったのは内緒の話。
Saturday, June 16th
僕も昔はストレートに物言いしてましたが、年を食うと「マイルド is 正義」に価値観が変わってきますね
けっこう僕、実は思ってもいない社交辞令混ぜてるんですよ
https://qiita.com/umanoda/items/93aec41213f8e3ce14c8
Qiita
# はじめに この記事は [How to write the perfect pull request - GitHub](
https://github.com/blog/1943-how-to-write-the-perfect-p...
これ読んで、PullRequestの書き方かいてないじゃん、と思ったわけです。
そのあと、体裁だけ整えればいいってもんじゃないよ、という意図だと気づきました。
ああ、そうなのか、と方向性を変えるきっかけになりました。
ああ、そうなのか、と方向性を変えるきっかけになりました。
慣れてないうちはガイドラインあると心の支えになりますね
何が正解というのはなくて、チームに合ったPRの投げ方はチームの数だけあります
PR よりもむしろ Issue の運用の仕方を気を付けたほうが良くて、
「この Issue は何をクリアしたらクローズされるのだろう」という条件が明確に提示されていることが好ましいです
僕も書かないことありますけど理想はそれです
仕事でGitHub使うのが一番習得早いんですけどね
自分は10件くらいPR投げた時点では「まだ慣れないな~」という感じで、100件超えたあたりから「なんか分かってきた気がしないでもない」って感じになりました
rebase も同じで、100回くらいやらないと正直馴染まないっす
あとレビューの仕方ですが、OSSで人的リソースがそこまで豊富ではないと難しいのですが、仕事とかで人がたくさんいる場合には「動作チェックレビュー」と「コードレビュー」を別々の人が並行で回したりできて、それで品質担保したりしてました
一休み・・・
十五夜先取りですね
季節感はないですねぇ。もともと季節感ない人ですし。カラオケではTUBE(夏)と槇原(冬)をよく歌います。
最近私は、米津玄師の早口についていけず修行中。。。
Monday, June 18th
joined #random.