Sunday, February 09, 2014

Computer Science Areas and Their Journals/Venues

A summary of Computer Science areas, abbreviations, and their corresponding journals and venues.

I started to link each of the journals/venues to each Computer Science area then found that I kept going to Microsoft Academic Search to look them up.

Artificial Intelligence (AI)

Bioinformatics (BIO)

Communications and Networking (COMM)

Compilers and Programming Languages (C+PL)

  • OOPSLA, POPL, PLDI, TOPLAS, CGO

Computer Architecture (ARCH)

  • ISCA, MICRO, DAC, ASPLOS, TCAD, SC

Computer Graphics (GRAPH)

  • TOG, CGA, TVCG, SIGGRAPH

Database (DB)

  • TODS, VLDB, Sigmod

Distributed Computing (DC)

  • TPDS, JPDC, ICDCS, ICPP

Human-Computer Interaction (HCI)

  • TOCHI, IJMMs, UMUAI, CHI, CSCW

Image Processing and Computer Vision (IPCV)

  • IJCV, TIP, CVPR, ICIP

Machine Learning (ML)

  • JMLR, ML, NECO, NIPS, ICML

Management Information Systems (MIS)

  • ISR, MANSCI, JMIS, EJIS, MISQ

Multimedia (MM)

  • MMS, TMM, IEEEMM, MM, ICMCS

Operational Research and Optimization (OR)

  • Math Prog, SIOPT, C&OR, Disc Appl Math

Security (SEC)

  • TISSEC, JCS, IEEESP, SP, USS, CSS

Software Engineering (SE)

  • TOSEM, ICSE, TACAS, ESE

Theory (TH)

  • JACM, SICOMP, STOC, FOCS, SODA

Saturday, February 08, 2014

Web Development Best Practices

The following are techniques for maximizing website performance on mobile devices. Personally, since more and more mobile devices are being used to browse content, I think all Web development should be done against the constraints of mobile. Please don't make a "full website" and a "mobile website". Those setups never look good or function well. Furthermore, redirecting a mobile request to a mobile site is expensive and slow. If you are dead set on the "full website" and "mobile website" configuration then make mobile the default and redirect to the full site if the request is not from a mobile device.

A mobile site needs to compensate when bandwidth or service becomes spotty. In other words, the site needs to be responsive even when the network is not. The same can be said for regular websites. Especially if you are trying to break into areas with questionable Internet service, e.g. Bolivar, Missouri, or questionable firewalls, e.g. China.

Eliminate HTTP Requests and Round Trips

  • Use CSS sprites to represent images embedded as inline data:URLs.
  • Use HTML5 application cache (app cache) to force the browser to cache all the unchanging content.
  • Insert dynamic content in the document via XHR (XMLHttpRequest).
    • Most effective if you can design the prefix of your page to fit into a single packet, 1492 bytes, render a basic framework for the page before any script is executed. To give the user immediate feedback that the page is loading, load the framework of the page as a fade effect by providing an opacity transitions from 0.0001 to 1.0 just after the framework is loaded. If you cannot get the basic framework of your page to fit into the first packet, then you can instead load a spinner or a logo, again as an opacity transition from 0.0001 to 1.0. The spinner or logo should be conditionally loaded after checking whether the app cache is already populated.
      • <script>
          if (window.applicationCache.status == 0) { // Reveal the spinner
        } else {
          // Page was loaded from app cache. Bring out the kitchen sink.
        }
        </script>
  • Make changes to minimize DNS lookups and redirects.

Use Compression

  • nuff said.

Manage JavaScript Parse Time

  • Move the vast majority of script to the bottom of the page.
  • Allow the browser to load your JavaScript without recognizing it as script and defer parsing and initial evaluation until needed.
    • To do this, set the type of the script to an unrecognized type and change it to text/JavaScript later. For example,
      <script type="deferred" id="module1">
        // deferred code here
      </script>
      When you are ready to use the script, reference the script tag by the id and change the type. The browser will parse and evaluate the script at that time.

Avoid Layout and Style Calculation

  • Avoid reading properties that rely on the position of elements on the page to be returned. Any such property could cause the browser to recalculate styles on demand and return the value to your script.

Monitor Request Size

  • Reduce the number of cookies you are using.
  • Ideally, all requests should be smaller than a TCP packet.

Preload Components

  • When the odds are good that you know what a user will request next then it is time to preload.
  • This can be seen in Google's Calendar website. The next day's events are loaded as the user clicks through each day, giving the effect that all of the data is already loaded.

Optimize Images

  • It is worth the time and effort to experiment with finding a good balance of image compression vs image quality.

Common Recommendations with Questionable Consequences

Make JavaScript and CSS External?

  • Inlining all your JavaScript and CSS into each webpage will deliver the best results in terms of speed. For maintenance reasons, you could use XHRs to fetch the JavaScript or CSS and the HTML5 database to store the resource for later reuse.

Make AJAX Cacheable?

  • Skip trusting the browser to cache AJAX responses. You're better off to build a full-blown write-through cache layer or a XHR caching layer on top of the HTML5 database.