JavaScript app developer

One year experience as a JavaScript app developer

With a headache I couldn’t even get up, laying in bed and realizing that I am already working as a JavaScript app developer for a year now. So maybe it’s time to write some down, and time is now 😛

Using React Native is actually quite easy. You will have troubles for sure, but none of them will stop you from getting things down. React Native is guaranteed to work on all the upcoming phones in 2017.

Situation

We only have 2 front-end developers, and we are a small team(4 people). We know nothing about Android or iOS native development, but we already know a Web-view app is not going to be “Native” easily.

Two choices

We were looking for every possible way to avoid having too many knowledge learning at the beginning. You don’t want your head to be exploded when the project is not even starting yet.

But after research, there are only two choices: Native Script or React Native. And I think there are two reasons why we didn’t pick Native Script:

Community

React Native clearly is the famous one, and the company like Facebook just make you feel safe. The community is very active, and many react native libraries could be found on the GitHub.

Debug

I don’t know what situation now, but one year before when I looked at Native Script, the debug tool is clearly not useful at all. It makes me feel like if I pick this framework on our project, I have to debug JavaScript by using “alert();” function if you know what I mean.

Surprise

So our project starts with React Native. And surprisingly it went well, especially when you are using Redux with it: painful to write, easy to maintain.

One year before, we don’t know any native development at all. One year later, at least I am sure I still only know a few. I never touched native side, although there is always some problem: Android Emulator is not able to access host file, Android Emulator adds “UTF-8” in restful API requests content-type, iOS is not able to access user cell phone number, iOS is not able to send SMS in the background and so on.

But we learn fast and there are also many solutions you can find on the internet. So now our app is already in App Store and will be on Google Play soon.

At last, thanks to Kartenmacherei that giving me this opportunity to learn React Native and working with talented teammates to bring the app go live.
The journey is full of challenges and joy.

How to hack time and determine one’s Time Value

How to hack time and determine one’s Time Value?

In today’s post, I want to hypothesize how to maximize one’s time value both in the short-term and the long-term. So let’s get right into it!

Each day, we have 24 hours to live, earn money, and create value. A back-of-the-envelope calculation provides the following:

24 hours = 8 hours of sleep + 8 hours of economic activity + 8 hours of family/friends/self time

So, in the short-term, we are spending about 8 hours a day (excluding weekend) or 40 hours a week to drive economic benefit for our lives. So if a person earns $4000/month, he or she is earning $1000/week, $200/day or $8.33/work hour.

So the person’s daily economic value is $200 and hourly value is $8.33. The more your salary increases, so does your ST time value.

It can further be enhanced with passive drivers such as savings and investment.

The remaining 16 hours of our day contributes to the long-term value of our time. Maintaining a regular schedule of healthy activities contributes greatly to the long-term value of time, including lifespan, and happiness. These 16 hours create a positive loop: if you are healthy, you are happy; if you are happy, you are healthy.

We can conclude that if person spends 8 hours a day to drive economic benefit, the remaining can be allocated to sleep, family, friend and me-time and still maintain his/her salary level and lifestyle.

The key is efficient time management and fungibility between each our hour of the 24 hours we are gifted each day.

Term “fungible” is often associated with gold and currency (by association, cryptocurrency included). If something, in our example time, is fungible, it can be traded for another unit of this substance and still bear the same value. If I borrow a $1 note from someone with serial number ending in 1, it still is worth $1 no matter what kind of medium I use to repay you. I can give a different note or coins or I can transfer it digitally.

Thus, if time is fungible, i.e. any 1 hour of my time is same as any other 1 hour of my time, the ideas represented in this post holds true.

Perl Scripts to Extract Rows and Columns from Many Excel Files

I had to aggregate rows and columns from about 100 MS Excel spreadsheet files from different sheets in the spreadsheets, they were reports filed by a hundred different offices, all the same format. Each extract was in a tab delimited format to throw into another spreadsheet. The first script combines all the rows in many Excel files into one file. The second script combines all the columns in many Excel files into one file. Why is this a common problem? Well MSExcel is a cheap and common report and analysis tool, everyone knows Excel and therefore everyone uses it. It is a common solution to have a bunch of people fill out a spread sheet, it is common to need to combine the spreadsheets into one file to analyze them.

The code is quick, dirty and ugly to boot. But it worked like a charm, in a couple hours of scripting I saved some people many many hours of screwing around with the 100 spreadsheets cutting pasting or making errors.

# Get rows from many Excel spreadsheets in a directory
###################################
#! /usr/local/bin/perl -w
    use strict;
    use Spreadsheet::ParseExcel::Simple;

my $excel_directory = 'Budget';
my $out_directory = 'xxxout';
opendir(EXCELDIR, $excel_directory) || die ("no excel directory");
my @excelfiles = readdir(EXCELDIR);
closedir(EXCELDIR);

chdir($excel_directory);
       my $LPHname;    # String to hold Local Public Health Name.
       my @sheetarray; # Array to hold the row.
       my $sheetcount; # Array element in the row.
       my $sheetname; # Name of the Excel spreadsheet.
       my $sheettemp;  # Temporary string to hold row for join.
       my $cellnumber;  # Cell number in the row.
       my $cellwanted;  # Cell number in the row.
       my $rowwanted;  # Row number wanted.
       my $county_namecell;  # Cell for county name.
       my $county_namerow;  # Row for county name.
foreach my $exxfilename (@excelfiles){
   if ($exxfilename =~ /^\.+.*/) { next; }
   my $xls = Spreadsheet::ParseExcel::Simple->read($exxfilename);
   foreach my $sheet ($xls->sheets) {
       $sheetname= $sheet->{sheet}->{Name}; # Sheet Name
       if ($sheetname !~ '2007 Budget') { next; }
       $sheetcount=0;
       $county_namecell=11;
       $county_namerow=1;
#      $cellwanted=4;
       $rowwanted=11;

       while ($sheet->has_data) {
            my @data = $sheet->next_row;
            $sheetcount++;
         if ($sheetcount==$county_namerow){
            $cellnumber=0;
            foreach my $ttcell (@data) {
                $cellnumber++;
                if ($cellnumber != $county_namecell ){next;};
                 $sheettemp=$sheetarray[$sheetcount];
#                 $sheetarray[$sheetcount]=join("\t",$sheettemp,$ttcell);
                 $LPHname=$ttcell;
            }
         } 

#        if (($sheetcount < ($rowwanted-1)) || 
               ($sheetcount > ($rowwanted+7))){next;}
         if ($sheetcount != $rowwanted){next;};
         $cellnumber=0;
         $sheetarray[$sheetcount]=join("\t",$sheettemp,$LPHname);
         foreach my $ttcell (@data) {
            $cellnumber++;
#            if ($cellnumber != $cellwanted ){next;};
            $sheettemp=$sheetarray[$sheetcount];
            $sheetarray[$sheetcount]=join("\t",$sheettemp,$ttcell);
         }
       }
    }
    foreach my $sheetline (@sheetarray){
        print $sheetline,"\n";
    }
}
exit


###############################################################
# Column extract.
# Get columns from many Excel spreadsheets in a directory
###############################################################

#! /usr/local/bin/perl -w
    use strict;
    use Spreadsheet::ParseExcel::Simple;


my $excel_directory = 'TEST';
opendir(EXCELDIR, $excel_directory) || die ("no excel directory");
my @excelfiles = readdir(EXCELDIR);
closedir(EXCELDIR);

chdir($excel_directory);
       my @sheetarray; # Array to hold the row.
       my $sheetcount; # Array element in the row.
       my $sheetname; # Name of the Excel spreadsheet.
       my $sheettemp;  # Temporary string to hold row for join.
       my $cellnumber;  # cell number in the row.
       my $cellwanted;  # cell number in the row.
       my $rowwanted;  # row number wanted.
       my $county_namecell;  # cell for county name.
       my $county_namerow;  # row for county name.
foreach my $exxfilename (@excelfiles){
    if ($exxfilename =~ /^\.+.*/) { next; }
    my $xls = Spreadsheet::ParseExcel::Simple->read($exxfilename);
    foreach my $sheet ($xls->sheets) {
       $sheetname= $sheet->{sheet}->{Name};


# Name the sheet to take stuff out of.
       if ($sheetname !~ '2007 Budget') { next; }
       $sheetcount=0;
       $county_namecell=11;
       $county_namerow=1;
       $cellwanted=2;
       $rowwanted=5;

       while ($sheet->has_data) {
            my @data = $sheet->next_row;
            $sheetcount++;
          if ($sheetcount==$county_namerow){
             $cellnumber=0;
             foreach my $ttcell (@data) {
                $cellnumber++;
                if ($cellnumber != $county_namecell ){next;};
                $sheettemp=$sheetarray[$sheetcount];
                $sheetarray[$sheetcount]=join("\t",$sheettemp,$ttcell);
             }
          }
          if (($sheetcount < ($rowwanted)) || ($sheetcount > ($rowwanted+5)))
             {next;}
#column boundary starting from rowwanted and getting cellwanted column.
#         if ($sheetcount != $rowwanted){next;};
             $cellnumber=0;
             foreach my $ttcell (@data) {
                $cellnumber++;
                if ($cellnumber != $cellwanted ){next;};
                $sheettemp=$sheetarray[$sheetcount];
                $sheetarray[$sheetcount]=join("\t",$sheettemp,$ttcell);
          }
       }
    }
}
foreach my $sheetline (@sheetarray){
    print $sheetline,"\n";
}
exit

Redesign of MNsure.org that uses MN Dept. of Revenue to Prescreen All Citizens

MNsure.org Website Failed and Never Improved

No testing of the site occurred before launch Oct. 1st, 2013. Many people could not make accounts or finish applications. Completed applications could not be processed, insurance companies could not get information from MNsure.

The worst problem was that nothing improved. The software process is a shambles, the design complex and unworkable, the contractors incompetent and venal and still no testing has ever occurred. MNsure’s Director April Todd-Malmlov resigned mid-December in an uproar of scandal.

The error filled difficult to use incomprehensible website and the disincentive of having people come to the awful website on their own initiative and fill out pages and pages and pages of jargonized information that is then attempted to be “verified” to slightly different information already collected is an exersize in futility and a guarantee of low participation. Few people can complete any transaction from the current website. It is like a Republican voting scheme: a design proven to turn people away.

MN Department of Revenue and Department of Human Services Already Have Information Needed to Get Most Enrolled.

The information is already collected. Social Security Number, dependents, income, address, food stamps, etc. Why collect it again?

Of the 450,000 people estimated to be without health insurance in Minnesota maybe 300k or more would qualify for MA and MNCare. The MN Department of Revenue has both Federal IRS and Minnesota tax forms. People could be pre-screened for Medical Assistance (Medicaid), MNCare and QHP (20% profit ripoff private insurance) tax subsidies.

County services and the MN Dept. of Human Services (DHS) would then have a list of people that qualify for MA/MNcare but do not yet have health care. People would then be contacted to verify information and finish enrollment by County workers and DHS through a website or paper form. Limited information would be needed to verify or update the prescreened information.

UPDATE: 3/31/2014
And here I thought I was so smart. West Virginia and 3 other states already scanned their citizens existing information and signed them up. From Charles Gaba’s ACASignups.net blog on ACA numbers 73% of the uninsured of West Virginia were signed up and no crush of people at the website:
“the reason West Virginia nearly doubled the projected number of enrollment was by identifying potential participants using information on existing food stamps and Medicaid applications. Only one of four states with this kind of auto enrollment, the process garnered around 118,000 enrollees.[in W. Virginia]”

The stupid wasteful advertising expenses of MNsure could be cut, we already know who qualifies. Verification time would be shorter than now (40 days is common) and most people could get enrolled without a problem.

Simplified Health Program Eligibility Would Speed the Process

Because of the complex obtuse eligibility rules for health programs or updates to information at Revenue there will be a fraction of people that prescreening can not easily verify. Simplified eligibility rules for MA and MNcare tailored to Department of Revenue information and update cycles would help keep that fraction small. Because of prescreening many of the difficult cases would be known beforehand and special handling could be prepared.

Pre-Screened Tax Subsidies Would Even Sell Ripoff 20% Profit Private Insurance (QHP)

With everyone prescreened people could check the website with only limited information to see eligibility for subsidies and amounts for policies that qualify without filling out pages and pages and pages of forms.

Single Payer Health Care Would Be Even Easier

Of course the most obvious improvement to health care for all is extending Medicare for all. No complex eligibility, no one left out.

MNsure.org Enrollment Lags Compared To Successful State Exchanges

The MNsure.org site is known as a website wobbling on the edge of failure. It is not known as a successful state health insurance exchange with its history of enrollment problems, Director resignations, shoddy venal contractors, never tested before opening for business, lack of improvement on the site until March 2014 when they started fixing missing pages and removing broken scripts. A few thousand users overwhelm the site and then users get maintenance screens and unauthorized errors. An outside contractor, Optum, hired to assess the website and software raised the possibility of scrapping the software altogether and starting over calling the software process broken with MNsure unable to make fixes to the site as of January 2014. The website can only run 18 hours per day and has had many outages, some for as long as 5 days. 20% of enrollment is from paper forms that really only got started in January 2014. The backlog of completed applications has been as high as 27,000 in March 2014 and the time interval of the backlog can be measured in months for many.

Maryland’s website software is going to be abandoned and use Kentucky or Connecticut’s version for its exchange. This is notable because it shares contractors and licensed software from IBM Curam and EngagePoint with MNsure. Maryland was able to get an effective paper application process started and enrolled 295,000.

The terrible website has definitely stifled enrollment, the question is how much has it been suppressed? My data is from ACASignups.net, the only blogger tracking national ACA enrollment state by state. I am looking at percent of uninsured enrolled and percent of total population enrolled.

  • Kentucky, population 4.4 million, 350,000 people have enrolled by March 27, 18% uninsured about 792,000. 44% enroll/uninsured, 8% enroll/population
  • Washington, population. 6.9 million, which has enrolled 500,000 March 28, uninsured is 1/7 or 14% or about 942,000. 53% enroll/uninsured, 5.5% enroll/population
  • Connecticut, population 3.6 million, 178,600 enrollments March 27, 337,000 uninsured. 53% enroll/uninsured, 7% enroll/population
  • Rhode Island, population 1 million, 69,400 enrollments March 8, 16% uninsured 140,000. 50% enroll/uninsured, 7% enroll/population
  • Minnesota, population 5.4 million, 150,000 enrollments March 27, 9.1% uninsured, about 490,000. 31% enroll/uninsured, 3% enroll/population

Enrollment Suppression Numbers at MNsure

Minnesota numbers of enrolled/uninsured and enrolled/population are quite a bit less than the successful states, I am guessing it is the terrible website. Here is what it would be if Minnesota matched the proportions of the successful state exchanges:

At 40% enrolled/uninsured enrollment would be 196,000 or 46,000 suppressed.
At 50% enrolled/uninsured enrollment would be 245,000 or 95,000 suppressed.

At 4% enrolled/population enrollment would be 216,000 or 66,000 suppressed.
At 5% enrolled/population enrollment would be 270,000 or 120,000 suppressed.
At 6% enrolled/population enrollment would be 324,000 or 174,000 suppressed.
At 7% enrolled/population enrollment would be 378,000 or 228,000 suppressed.

So between 46,000 and 228,000 suppressed enrollment from a bad website. These numbers are only estimates but it can be fairly certain that 10’s of thousands did not enroll at the website from the screwups at MNsure. And remember 20% of the finished applications are paper, not on the website, I am not counting that against MNsure.

4 States Auto Enrolled People

See Prescreening People to Enroll in Health Insurance to see how W. Virginia doubled projected enrollment by using data already gathered from food stamp programs and previous Medicaid applications to auto-enroll citizens using HealthCare.gov, the Federal website.
West Virginia, population 1.85 million, 105,000 Medicaid only enrollments, 14% uninsured 259,000, 41% enrolled/uninsured, 6% enrolled/population.

I do not know the other 3 auto enrolling states that used pre-screening processes, let me know if you find out.

MNsure Lags on Processing Paper Applications Too

Maryland’s, population 5.9 million, used 200 additional clerks to process forms and enrolled 295,000, MNsure, with a similar population, only had 50 clerks and 170,000 enrollment. The lack of a robust paper process also suppressed MNsure enrollment. (Minnesota had the fewest additional clerks from April 3, 2014 testimony to Congress Committee chaired by Rep Lankford of exchanges from CA, HI, MN, OR, MD, MA)

Single Payer Health Care Would Be 100% Enrollment

Of course the most obvious improvement to the website would be extending Medicare for all. No complex eligibility rules, no one left out, may not even need a web site to sign up.

MNsure.org Simple Design Problems and Solutions

First, the MNsure.org site is a terrible design, everyone who has used it knows that from their own experience and what is more it has never been user tested to fix the user interface problems. After using the site and complaints I have seen online here are a few serious problems:

  • People are having trouble creating an account with the rigamarole they put you through with bogus security questions sucked from your credit history.
  • Bad code that fails on some web browsers and not others.
  • There are many questions about insurance jargon and policy coverage and comparing health coverage, eligibility.

Finding Quick Fixes to Increase Enrollment

Getting a few user tests done by some local user interface professionals could be done in a few days. Some basic user goals and scenarios could be tested and improved within a week. A couple suggestions to get started:

  • finding a navigator to assist enrollment
  • getting the paper form to use instead of the website
  • finding out the status of an application without having to call
  • shopping for insurance without creating an account.

The same approach can be taken to improve website speed and performance. Local web site performance consultants can be hired for a day or two to assess problems, propose quick fixes and get some improvements.

Will this approach fix all the problems at MNsure? NO. There are difficult software problems of billing, interface to insurance companies, process flow of the website, bugs in the code, etc. But there are quick improvements that can be made, the Federal site, HealthCare.gov did some of these already.

Quick Examples of Scenarios and Some Heuristic Fixes

Finding Navigators to Help Apply

For many people the web site is just too much of a barrier and they need alternative methods to sign up and/or help from Navigators.

There is a prominent link on the front page to become a “Navigator” and a teeny link that goes to a page that goes to another teeny link for the list of “assisters” which are the same as a navigator but now called something else. There are many citizens needing help negotiating the rules to get health coverage. When I look on Google for “MNsure Navigator List” I do not see the list at the top of the page and the list is not apparent and not among the choices on the result page.

  • Get rid of the “assister” label and call them all Navigators or the other way around. Calling navigators assisters and assisters navigators just makes it hard to find the list.
  • Instead of just a big button on the home page for joining as a Navigator add a big button to point to the list of Navigators so people get help enrolling by actually finding Navigators.

Finding Paper Forms to Apply

At least if you look up “MNsure paper form” on Google you find it number one on the result page. But on the home page it is located under a teeny little link. It needs a great big button on the home page.

Get Rid of the Big Pictures and Popup Window on the Home Page

Put important info “above the fold” instead of below worthless pictures. The popup window is an annoyance that should go away and its info should be on the home page.

Single Payer Health Care Would Be Even Easier

Of course the most obvious improvement to the website would be extending Medicare for all. No complex eligibility rules, no one left out, may not even need a web site to sign up.

MNsure.org PR Propaganda and Enrollment Projections

One of the first actions of the new Director Scott Leitz was to hire a full crew of PR hacks to improve the tone of the media coverage of MNsure. They have tried to do several propaganda pushes of blatantly fake stories as well as missed opportunities to tell actual successes.

MNsure.org PR Propaganda On Website Uptime

In the MNsure Board reports website uptime is reported many weeks as 100%. This is even though MNsure.org is closed 6 hours every day or 25%.

When I do math this means that the website is open for business 75% of the time. In Oct-December MNsure.org closed most of the weekend as well as 8 hours/day on week days. The standard for a website is 24/7, not bankers hours. The metrics should show the improvement from a horrible October to a slight improvement in March, not a phoney “100%” for almost every time period from October to March. Other ACA state websites and the Federal Healthcare.gov have no downtime scheduled everyday, so this is a deliberate fogging of IT problems MNsure.org.

MNsure.org PR Propaganda Line On MNcare Enrollment

Another fake story is the equating of MNcare (state subsidized) enrollments as “they should be counted as QHP” [private for profit ripoff insurance] enrollments because the program is not available in all other states. The population served by MNcare is up to 200% of the Federal poverty measure. There is no way people can pay for high deductible 20% profit insurance at that income level. The PR hacks should have gone for the “Big Lie” and declared the expanded Medicaid (MA) enrollments not available in the Republican controlled states should also be counted as QHP enrollments, then they would have met or exceeded the goals of MNsure QHP enrollment. They could have had another “100%” success story.

The disturbing part of the MNcare story is the plateau of enrollments and the backlog of 27,000 finished applications. It seems that MNsure is trying to drive MNcare and Medicaid applicants into the QHP markets by holding up applications instead of processing finished applications.

MNsure.org PR Propaganda Line On QHP Enrollment and March 31 Deadline

Another PR problem is the relentless concentration on getting QHP enrollment without a website or support program that makes that enrollment possible and the PR line that enrollment stops March 31st.

The reality is that the QHP market is small and consists of people who are jobless, low income, work independently or do not get health insurance as part of a job. Of the ~500K people without insurance in Minnesota over 1/2 qualify for Medicaid or MNCare. The uncertain tax subsidies are not enough inducement at the higher incomes to keep customers once they try the horrible website and compare that experience to other private markets for insurance.

The terrible website, complex rules to get a tax subsidy for QHP badly implemented at MNsure, the long backlog for finished applications, no paper application option until about January, lack of phone support and delays in training and deploying adequate navigator support mean that most of the higher income individuals in the individual insurance market have gone to private insurance brokers to buy policies. Only in the last few weeks has phone support been adequate to deal with the crappy web site. Only in the last few weeks have there been enough Navigators and Navigator marketing to assist people signing up.

Actually there is no March 31st deadline for most people. MA and MNcare have NO DEADLINE and will continue signing up citizens! It is only private insurance that will stop signing up suckers, I mean customers.

The missed success story is the larger than expected Medicaid (MA) and MNcare enrollment that is expanding in proportion of enrollments every month and is almost 72% of enrollments. This is almost Single Payer insurance and the critical mass of people signing up (300,000+?) will make Single Payer a reality as combined with VA and Medicare Single Payer will begin to control the market in Minnesota.

I expect that MA/MNcare will be 90-95% of enrollments by next October when QHP enrollment opens again and then few QHP will sign up. People without insurance usually do not have the money to buy private 20% profit ripoff insurance. In a few years as employers drop insurance benefits from more and more jobs and changes to the system take place I expect Single Payer MA/MNcare enrollments to increase as demands for Single Payer are made by the middle class.

Backlog is the Hidden Story With MNsure PR

The huge backlog of unprocessed finished applications is the story ignored by MNsure and the media even though the Legislative Auditor has repeatedly critiqued the problems of the Dept. of Human Services (DHS) past performance with its backlog in Health Services over many years. MNsure seems to be using this backlog to drive citizens into the private insurance market to get its fees as citizens eligible to get MA and MNcare get desperate to avoid tax penalties and get health coverage.

Single Payer Health Care Would Be Even Easier

Of course the most obvious improvement to health care for all is extending Medicare for all. No complex eligibility, no one left out.

70% Enrolled In MA And MNCare Single Payer. People Reject Private For Profit Ripoff Insurance.

Data is from a MNsure press release Feb 21, 2014 Citizens Reject Private Ripoff Insurance

    31,088 Minnesotans selected private health plans
    21,574 Minnesotans enrolled in MinnesotaCare
    48,682 Minnesotans enrolled in Medical Assistance (MA)
    101,344 total enrollments

MA+MNCare=Single Payer or (48,682+21,574)/101,344 = 69%
It is obvious that people reject the crooked private insurance that can extract a profit of 20% from citizens. This rate is up from 66% Single Payer on Feb 12, more and more people choose the single payer alternatives.

1/5 Finished Applications Stuck, 2/5 Accounts Never Get Health Care From MNsure

From Feb 12 document: https://www.mnsure.org/images/Bd-2014-02-12-Dashboard.pdf page 3 labeled “Applications and Enrollment through MNsure”:

“161,589 accounts created”
“118,2668 applications submitted”, A Typo on the web page, my guess is 118,268.
“92,498 enrollments”

From this information we have the following conclusions:

118,268 – 92498 = 25,770 completed applications have not yet been enrolled or 25,770 / 118,268 = 21.7% or over 1/5 cannot enroll after completing an application. That is a massive failure rate to enroll completed applications, no reasons given.

161,589 – 92,498 = 69,091 accounts have not yet enrolled 42.7% or over 2/5 have not made it through the process.

Something is seriously wrong with MNsure when 2/5 fail to get health care. $150 million in resources were thrown away on non-working software and expensive IT contractors at $350/hr for non-working processes. For $20 million 200 case workers could have manually enrolled the people for a savings of $100+ million including a simple site to let people submit application forms online. This is unbelievable that after 3 years the leadership of MNsure is allowed to continue to work for the state and do this to citizens. April Todd-Malmlov the Director who resigned in disgrace did not work alone. Plenty of other idiots helped destroy this program and should pay with their careers.

Simple Single Payer Must Be the Solution

I would rather have a simple single payer health care system, no eligibility rules, no 20% profit insurance sold by crooks, everyone pay just like Medicare like the rest of the civilized world.

Database Management: Optimizer, Statistics and Performance

Ask yourself: What is the purpose of optimization statistics? It is to get statistics for the data in the RDBMS so the optimizer can create a query plan to find a fast path to the data, it is part of database management.Statistics are created by running ‘ANALYZE’ in Oracle, ‘update statistics’ in Informix or ‘vacuum’ in Postgresql and other utilities in other RDBMS. But a performance problem may occur if the processing to get the statistics takes a significant amount of time in a large application.

Sometimes people see large increases in performance from statistics and think that they must run the statistics jobs to reflect every change in the data. This is usually not needed, the optimizer will probably pick the same method to get data from a table that has a million rows as when it has a million and a half or even ten million. So, if the time to process statistics is crippling the application performance to improve performance, what to do?If table sizes do not change drastically and the distribution of values do not change drastically the easiest way to optimize runtime of the statistics job is to run it fewer times. Instead of five times a week, run it once a week, or once a month or split the job to run a few tables per day.

Or just once if the size and distribution of the data is more or less static and no indexes are changed.If a table is fluctuating in size by magnitudes of “X” and/or attribute value distribution has a “large” difference over time run the statistics job on that particular table more often if it makes a difference in the performance of the application. If an index is added to a table, also run the statistics on that table.Some RDBMS utilities can get statistics on a sample of the data, or some subset of statistics. The statistics job will run faster.

The idea is that some statistics, even if not complete or totally accurate, will help the optimizer enough to get a fast path to the data.