Page2RRS

• 31 Oct 2009 02:47

  2009年10月30日

  ・買ってしまった

  ■_

  Perl 6のデザインミーティングで。

  Journal of chromatic (983)
  
  Perl 6 Design Minutes for 21 October 2009
  
  [ #39819 ]
  
  The Perl 6 design team met by phone on 21 October 2009. Larry, Allison, Patrick, Will, 
  Nicholas, and chromatic attended.
  
  Nicholas:
  
      * I don't like UTF-16
      * Perl 5 should be able to read it big-endian and little-endian
      * Larry wrote the original code
      * I've fought several bugs in it
      * you get the benefit of larger sizes and variable length
      * but you have to deal with partial reads
      * I don't know if Rakudo will have to deal with it, but blah!
  
  

  まあ、UTF-16大好きってひとはいてもごく少数だろうなあ。

  ■_ short coding?

  stackoverflow.com で、自分の作った awk スクリプトを改良したいのだけど… というお話。

  How can I remove selected lines with an awk script? - Stack Overflow
  
  I'm piping a program's output through some awk commands, and I'm almost where I need 
  to be. The command thus far is:
  
  myprogram | awk '/chk/ { if ( $12 > $13) printf("%s %d\n", $1, $12 - $13); else  printf("%s %d\n", $1, $13 - $12)  }  ' | awk '!x[$0]++'
  
  
  The last bit is a poor man's uniq, which isn't available on my target. Given the 
  chance the command above produces an output such as this:
  
  GR_CB20-chk_2, 0
  GR_CB20-chk_2, 3
  GR_CB200-chk_2, 0
  GR_CB200-chk_2, 1
  GR_HB20-chk_2, 0
  GR_HB20-chk_2, 6
  GR_HB20-chk_2, 0
  GR_HB200-chk_2, 0
  GR_MID20-chk_2, 0
  GR_MID20-chk_2, 3
  GR_MID200-chk_2, 0
  GR_MID200-chk_2, 2
  
  What I'd like to have is this:
  
  GR_CB20-chk_2, 3
  GR_CB200-chk_2, 1
  GR_HB20-chk_2, 6
  GR_HB200-chk_2, 0
  GR_MID20-chk_2, 3
  GR_MID200-chk_2, 2
  
  That is, I'd like to print only line that has a maximum value for a given tag (the 
  first 'field'). The above example is representative of the at data in that the output 
  will be sorted (as though it had been piped through a sort command).
  

  
  If you find yourself squeezed for space and speed and this is not premature 
  optimization, you can replace your if ... printf ... else ...printf ... with the 
  shorter and, at least on my system, faster "poor man's abs()": 
  printf("%s %d\n", $1, (($12 > $13) * 2 - 1) * ($12 - $13))`
  
  

  
  Also, note that your awk command that filters lines on /chk/ can be combined into my 
  script below (with mods to save the appropriate "prev" fields instead of the 
  whole line, etc.) so you're only calling awk once. At the top of my script, s would be 
  set to (($12 > $13) * 2 - 1) * ($12 - $13) (untested)
  
  

  Based on my answer to a similar need, this script keeps things in order and doesn't 
  accumulate a big array. It prints the line with the highest value from each group.
  
  #!/usr/bin/awk -f
  {
      s = substr($0, 0, match($0, /,[^,]*$/))
      if (s != prevs) {
          if ( FNR > 1 ) print prevline
          prevval = $2
          prevline = $0
      }
      else if ( $2 > prevval ) {
          prevval = $2
          prevline = $0
      }
      prevs = s
  }
  END {
      print prevline
  }
  
  

  
  Much faster, and because memory is a concern (it's an embedded environment) I'm 
  switching to this as the correct answer. – Jamie 2 hours ago
  
  

  If you don't need the items to be in the same order they were output from myprogram, the following works:
  
  ... | awk '{ if ($2 > x[$1]) x[$1] = $2 } END { for (k in x) printf "%s %s", k, x[k] }'
  
  

  Nicely done. Thanks a bunch.
  

  Just missing the "\n" in the printf(). Otherwise perfect.
  

  Ah, right. I had that in my test version but forget it when typing it here. :)
  

  for xx in yy で列挙したときの順序について言及してますね。

  ■_ 七つの

  あとでや(ry

  
  
  The 7 characteristics of simple code (KISS) | Making Good Software
  
  I used to believe that the most important quality of code is its extensibility. The 
  code had to be prepared for future changes so I would code lots of things not 
  necessary now. But after realizing that I never was right upfront guessing what the 
  future changes will be, and after having quite a few maintenance and handover 
  nightmares, a few a years ago I decided that I will take the opposite approach to what 
  good code is. Ever since I did that, I am every day more convinced that the key 
  characteristic of good code is simplicity. Simple code is easy to read and easy to 
  change. And because it is simple, it is less prone to have bugs (the more complex the 
  algorithm you are creating the more changes to make a mistake).
  
  Whenever you are coding, I recommend you to check every time if your code is still 
  simple, and remember: “there are no hard problems, only hard solutions”
  
  The seven main characteristics of simple code are:
  
  1.- Easy to read. (読みやすく)
  
  Simple code doesn’t need additional documentation, or it only needs minimal 
  documentation to be understood
  
  2.- Easy to use. (使いやすく)
  
  Whoever is using your code will find it intuitive to use your objects.
  
  3. Easy to change. (変更しやすく)
  
  Simplicity means that there is no duplicated logic. A change should match a single 
  place in your code.
  
  4. Doesn’t use any non-necessary third party, tool or technology.
    (必要のないサードパーティ製のツールや技術を使わない)
  
  Through my experience I have observed how some developers just love to use 
  technologies, tools and frameworks just for the sake of making the project more “cool”. 
  Every time you use them, you are adding extra complexity, and extra complexity means 
  that is more difficult to understand, to maintain and is more prone to failures.
  
  5. It looks simple. (シンプルに見えるように)
  
  If it doesn’t look simple, it is not simple! You know your code is simple if when you 
  finish you are astonished at how simple the final solution is and you ask yourself how 
  it was possible that it took you so long.
  
  6. Lean. (最低限のものを)
  
  It only does what is necessary, and nothing else. I think most seasoned developers 
  would agree that trying to anticipate the problems your code will have to face in the 
  future is impossible.
  
  7. Is straight forward.(単刀直入に)
  
  It doesn’t have unnecessary indirections; the most important operations only require 
  a straight method call.
  
  How can we develop simple code?
  
  The key of producing simple code is continuous refactoring, and the only way to do 
  this is continuous testing.
  
  You are going to need refactoring because every time you add a new line to your 
  algorithm, you are probably making it more complex. So every now and then you should 
  refactor to get it back to a simple stage.
  
  You need many tests because you are doing so much refactoring, and if you don’t have 
  a safety net you are going to introduce bugs into your system.
  
  

  ■_

  • ASCII.jp：～師範！　今日公開のUbuntu9.10を解説してください！～｜行っとけ！　Ubuntu道場！
  • 方法改善は 「4つのポイント」を見逃さないことがコツ!!（2/4） － ＠IT MONOist「作業改善の尻切れトンボ」のもう一つの原因は、新しい方法をいくらも試さないであきらめてしまうことです。
  • .NET TIPS － ＠IT
  • InfoQ: IronSchemeが近く最終リリースされるIronSchemeはコマンドプロンプトから実行できるREPL環境として利用できる。また、.NETアプリケーションにライブラリとして埋め込んで使うことも可能だ。 .NETの32または64ビット環境か、Monoの32ビット環境で動作する。
  • InfoQ: アジャイル開発を成功に導く26のヒント1つの作業を完全に終えてから次の作業を開始しなさい。 決定することを恐れるな。そして、以前の決定を変更することを恐れるな。 測定、測定、そして測定。 システム中心ではなく人間中心の設計をするべし。 早すぎる最適化は諸悪の根源。 機能を一般化しすぎるな。 コードの行数を計測するな。 ソフトウエアはプラスチックだ。 新しい言語を発明するな。
  • InfoQ: MacRuby 0.5ベータが登場。JIT、AOT、GCDサポート、GILの削除を実現ripper、digest、socket、zlibといったC拡張は少し修正することで動くようになっています。将来のリリースでは、MRI C拡張APIをフル実装する計画です。
  • The Busy Beaver Problem - good coders code, great reuseThe busy beaver problem is a fun theoretical computer science problem to know. Intuitively, the problem is to find the smallest program that outputs as many data as possible and eventually halts.

  1. 2009年11月(上旬)

  Permalink  |  View Entire Page

Search the Site

Custom Search