Saturday, February 06, 2010

Securing Amazon AMIs

http://www.cloudiquity.com/2009/04/system-hardening-guidelines-for-amazon-ec2/

Saturday, January 30, 2010

Cool iPhone Overlay UI

http://developer.apple.com/iPhone/library/samplecode/HeadsUpUI/index.html

also:
http://www.skylarcantu.com/blog/2009/08/14/custom-uialertview-color-chooser/

Screen grab:
http://www.skylarcantu.com/blog/2009/10/16/saving-a-view-as-an-image/#more-299

In general a good read:
http://www.skylarcantu.com/blog/category/iphone-development/

http://joris.kluivers.nl/iphone-dev/?p=CustomAlert

Wednesday, January 27, 2010

Tomcat Manager XML Output

http://www.informit.com/guides/content.aspx?g=java&seqNum=273

Tuesday, January 26, 2010

Misc Items of Interest

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1601&categoryID=148
http://www.dragthing.com/blog/?p=246

Wordpress Plugins to Try

Can't say I like 'em yet since I haven't tried them:
http://scribu.net/wordpress/front-end-editor
http://www.onextrapixel.com/2009/07/17/the-autopsy-of-wordpress-as-cms-with-25-great-wp-plugins-designs/

Friday, January 22, 2010

iPhone Calendar View

http://code.google.com/p/kcalendar-iphone/
http://stackoverflow.com/questions/1201285/is-there-any-in-built-calendar-view-in-iphone-sdk


Not iphone, but general:
http://www.ibm.com/developerworks/xml/library/x-googleclndr/?S_TACT=105AGX01&S_CMP=HP
http://phpicalendar.net/

Saturday, January 16, 2010

Friday, January 15, 2010

Critical Measures for HIT Integration

  • Reconciled list of patient medications used vs. prescribed vs. filled
  • Physician alerts for drug interactions
  • physician alerts for test results
  • physician prompts at the time of visit
  • alert to chronic illnes risks, and query existing registries
  • patient review of EMR data --- and updates
  • predict quality by risk-based scores

measure the following which predict success:

  • clinical time saved
  • usability complaints/support tickets
  • use vs. customization vs. departments
  • amount of training sessions required in minutes or hours

measure the following before and after HIT use (survey):

  1. relative advantage consistent with values and needs
  2. ease of understanding and use
  3. consistent with values and needs
  4. experimentation
  5. ovservability and example satisfaction

Sunday, January 10, 2010

Advancing Meaningful Use of EHR

Critical areas of focus for Healthcare IT (HIT) include:

1. translating incorporating the results of research into health IT products
2.

Creating breakthrough solutions, technologies, and services, which may be applied in health IT in the near- and long-term, and which address identified challenges and opportunities relevant to the adoption and meaningful use of health IT;
3.

Identifying a range of model (proof-of-concept) systems that serve as motivating and unifying forces to drive fundamental research in health IT; and
4.

Encouraging effective use of health IT through rapid dissemination of research results, findings on innovations and novel tools, to developers and purchasers of health IT

Major topics for research could include:

• Creating models that support dynamic abstraction of clinical information
• Techniques for parsimonious information display information that simplifies, while capturing essential features of a clinical decision problem
• Understanding decision making under stress and time pressure, and its implications for cognitive support
• Communication to clinicians, addressing message content and delivery, that blends with workflow
• Methods to support decisions that involve multiple stakeholders, taking into account their preferences and utilities
• Methods for minimizing and simplifying, when it is necessary, manual data input by clinicians

Monday, January 04, 2010

Be careful changing app name in Xcode

Apart from the fact that the PRODUCT_NAME var simply did not work, changing the name:
http://www.iphonedevsdk.com/forum/iphone-sdk-development/8962-change-iphone-app-name.html
also means you need a new profile for ad hoc! C'mon Apple! Sheesh.

Wednesday, December 30, 2009

Augmented Video on iPhone

http://www.morethantechnical.com/2009/08/09/near-realtime-face-detection-on-the-iphone-w-opencv-port-wcodevideo/
http://www.morethantechnical.com/2009/05/06/iphone-camera-frame-grabbing-and-a-real-time-meanshift-tracker/

video feed grabber:
http://github.com/norio-nomura/iphonetest/tree/master/CameraTest/Classes/

UIGetScreenImage post:
https://devforums.apple.com/message/149553#149553
http://www.tuaw.com/2009/12/15/apple-relents-and-is-now-allowing-uigetscreenimage-for-app-st/

http://pastie.org/235372.txt

Government Standards for Cloud Computing Security

http://csrc.nist.gov/groups/SNS/cloud-computing/index.html

Thursday, December 24, 2009

Useful iPhone SDK articles

http://www.edwardbenson.com/2009/01/10/creating-a-blocking-nag-screen-with-nsuserdefaults/
http://iphoneinaction.manning.com/iphone_in_action/2009/09/core-data-part-4-inserts-updates-deletes.html
http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UITextField_Class/Reference/UITextField.html#//apple_ref/occ/instp/UITextField/leftView
http://regexkit.sourceforge.net/RegexKitLite/
http://forums.macrumors.com/showthread.php?t=473359
http://blogs.oreilly.com/iphone/2009/01/defining-legal-input-character.html
http://stackoverflow.com/questions/433337/iphone-sdk-set-max-character-length-textfield
http://groups.google.com/group/three20/browse_thread/thread/1dc38ac9d7176b77
http://github.com/klazuka/TTRemoteExamples

Also another useful tip:
Also, you can pull up the preferences file in the plist editor if you are running on the simulator. You will find the file in (at least on the Mac):

~/Library/Application Support/iPhone Simulator/Users/Applications//Library/Preferences/.plist

Decompiling:
http://tungchingkai.blogspot.com/2009/02/how-to-decrypt-iphone-ipa-file.html
http://dvlabs.tippingpoint.com/blog/2009/03/06/reverse-engineering-iphone-appstore-binaries

Using zlib:
http://stackoverflow.com/questions/289274/error-when-import-zlib-in-iphone-sdk
http://samuraiblog.com/wordpress/2009/11/02/compressing-nsdata-objects-using-zlib/

Wednesday, November 04, 2009

PayPal Mass Pay Disbursements

How is Mass Pay Disbursements product different than Adaptive Chained Payments??
Their examples of disbursements include several overlapping scenarios:
  • marketplaces
  • rebates
  • commissions
  • affiliates
  • rewards
  • games/gambling
These are the same ones they discussed in the Adaptive Payments session.

Answer: volume --- MassPay up to 5K in one batch and async. Mass Payment API - 250 per API call and async. Pay API (adaptive) - up to 6 buy is realtime sync.

Hmmm seems that they pull each txn from the bank SEPARATELY. How much will the bank charge you!?

2% per payment with $1.00 max. Sender pays. Might be the new pricing model soon.

Friday, October 30, 2009

x264 encoding options

One of H.264's most useful features is the ability to choose among many combinations of inter and intra partitions. Pictures are typically in units called macroblocks. A macroblock has typically the size 16x16 pixels and can have different types. If the macroblock type is Intra (I), that part of the decoded image is completely replaced by a new texture, while if the macroblock type is Inter (P) the decoded macroblock data is added to what was previously decoded in that macroblock area. P-macroblocks can be subdivided into 16x8, 8x16, 8x8, 4x8, 8x4, and 4x4 partitions. B-macroblocks can be divided into 16x8, 8x16, and 8x8 partitions. I-macroblocks can be divided into 4x4 or 8x8 partitions. Analyzing more partition options improves quality at the cost of speed. The default is to analyze all partitions except p4x4 (p8x8, i8x8, i4x4, b8x8), since p4x4 is not particularly useful except at high bitrates and lower resolutions. Note that i8x8 requires 8x8dct, and is therefore a High Profile-only partition. p8x8 is the most costly, speed-wise, of the partitions, but also gives the most benefit. Generally, whenever possible, all partition types except p4x4 should be used.
When encoding with h264, the screen is divided into 16x16 Macroblocks (MBs). These blocks can be subdivided further into partitions of various sizes (16x8, 8x16, 8x8, 4x4). Motion estimation is better with smaller subpartitions, but the overhead for such information is similarly increased.
DCT block size is separate from motion block ("partition") size. The DCT has a choice of 8x8 or 4x4. Motion partitions have a choice of 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, or 4x4. Each (inter-) macroblock has both a DCT block size and some motion partition size(s). The only restriction on combining the two is that partitions can't be smaller than their DCT blocks.
Small partitions provide better prediction but cost more bits. There is no overhead one way or the other for DCT block size, but also one isn't always better compression than the other, so that decision is based just on which one is more appropriate to the given image region.
That said, high profile also introduced a new intra partition, "i8x8". Intra partition sizes now have a choice between 16x16, 8x8, and 4x4, which is decided based on prediction quality vs bit cost just like motion partitions are.
In x264, --8x8dct enables high profile, and x264 allows i8x8 partitions if high profile is enabled, but they should not be confused as being the same feature.
Here's where I put most of my emphasis in the tests for mobile:
    -refs (FFmpeg)
    One of H.264's most useful features is the abillity to reference frames other than the one immediately prior to the current frame. This parameter lets one specify how many references can be used, through a maximum of 16. Increasing the number of refs increases the DPB (Decoded Picture Buffer) requirement, which means hardware playback devices will often have strict limits to the number of refs they can handle. In live-action sources, more reference have limited use beyond 4-8, but in cartoon sources up to the maximum value of 16 is often useful. More reference frames require more processing power because every frame is searched by the motion search (except when an early skip decision is made). The slowdown is especially apparent with slower motion estimation methods. Recommended default: -refs 6
      -deblockalpha (FFmpeg)
      -deblockbeta (FFmpeg)
      One of H.264's main features is the in-loop deblocker, which avoids the problem of blocking artifacts disrupting motion estimation. This requires a small amount of decoding CPU, but considerably increases quality in nearly all cases. Its strength may be raised or lowered in order to avoid more artifacts or keep more detail, respectively. Deblock has two parameters: alpha (strength) and beta (threshold). Recommended defaults:-deblockalpha 0 -deblockbeta 0 (Must have '-flags +loop')

      me_method (FFmpeg)

      dia (x264) / epzs (FFmpeg) is the simplest search, consisting of starting at the best predictor, checking the motion vectors at one pixel upwards, left, down, and to the right, picking the best, and repeating the process until it no longer finds any better motion vector.

      hex (x264) / hex (FFmpeg) consists of a similar strategy, except it uses a range-2 search of 6 surrounding points, thus the name. It is considerably more efficient than DIA and hardly any slower, and therefore makes a good choice for general-use encoding.

      umh (x264) / umh (FFmpeg) is considerably slower than HEX, but searches a complex multi-hexagon pattern in order to avoid missing harder-to-find motion vectors. Unlike HEX and DIA, the merange parameter directly controls UMH's search radius, allowing one to increase or decrease the size of the wide search.

      esa (x264) / full (FFmpeg) is a highly optimized intelligent search of the entire motion search space within merange of the best predictor. It is mathematically equivalent to the bruteforce method of searching every single motion vector in that area, though faster. However, it is still considerably slower than UMH, with not too much benefit, so is not particularly useful for everyday encoding.

      One of the most important settings for x264, both speed and quality-wise. Looking at full vs. hex vs. umh.

      -subq 6 (FFmpeg)

      1: Fastest, but extremely low quality. Should be avoided except on first pass encoding.

      2-5: Progressively better and slower, 5 serves as a good medium for higher speed encoding.

      6-7: 6 is the default. Activates rate-distortion optimization for partition decision. This can considerably improve efficiency, though it has a notable speed cost. 6 activates it in I/P frames, and subme7 activates it in B frames.

      8-9: Activates rate-distortion refinement, which uses RDO to refine both motion vectors and intra prediction modes. Slower than subme 6, but again, more efficient.

      An extremely important encoding parameter which determines what algorithms are used for both subpixel motion searching and partition decision. Checking 6 or 8.


See also:
http://www.gdargaud.net/Hack/HtcHero.html (Android notes)
http://multimedia.cx/eggs/video-coding-concepts-quantization/ (and see the Wikipedia reference for more math)
http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

BlackBerry Video specs

For Wordpress Video, right now each format is hard coded, so we'll want to make this more intelligent. Rather than build this from scratch, I'll try this on encoding.com or similar to see if they handle it well:

Why Google Android 1.6 will FAIL

I think that Google has flown the coop if they think they can drop support for such an important technology:

Other Notes and Resolved Issues

  • This SDK release adds support for Eclipse 3.5 (Galileo) and deprecates support for Eclipse 3.3 (Europa).
  • We regret to inform developers that Android 1.6 will not include support for RFC 2549
  • The issue preventing adb from recognizing Samsung Galaxy devices (linux SDK only) has been fixed.

Google Android Video Codecs

http://blogs.zdnet.com/Burnette/?p=1133
and to see the gory details:

Typical streams look like this:

  • 3GPP - lower quality, H.263, AMR-NB audio, bit rates up to 192Kbps
  • MPEG-4 - higher quality, H.264, AAC audio, Bit rates up to 500Kbps
Also from the SDK 1.6:

Emulator Skins, Android 1.6 Platform

The Android 1.6 platform included in the SDK provides a new set of emulator skins, including:

  • QVGA — 240 x 320, low density (120 dpi)
  • HVGA — 320 x 480, medium density (160 dpi)
  • WVGA800 — 480 x 800, high density (240 dpi)
  • WVGA854 — 480 x 854, high density (240 dpi)

Besides these defaults, You can also create an AVD that overrides the default density for each skin, to create any combination of resolution/density (WVGA with medium density, for instance). To do so, use the android tool command line to create a new AVD that uses a custom hardware configuration. See Creating an AVD for more information.