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.

Saturday, April 13, 2013

Properties of Deliberate Practice

Some of the following is a couple pages from Talent is Overrated. It is a good book, if you care about improving your performance and agree that hard work is the way to do it then you should buy it. Most of the following is a personal note for myself to refer back to when defining and refining my own 'properties of deliberate practice'.

The properties of deliberate practice have been studied as key components of self-regulation. Effective self-regulation is something you do before, during, and after the work activity itself.

Before the work.

Self-regulation begins with setting goals. These are not big, life-directing goals, but instead are more immediate goals for what you're going to be doing today. In the research, the poorest performers don't set goals at all; they just slog through their work. Mediocre performers set goals that are general and are often focused on simply achieving a good outcome - win the order; close out my positions at a profit; get the new project proposal done. The best performers set goals that are not about the outcome but about the process of reaching the outcome. For example, instead of just winning the order, their goal might be to focus especially hard on discerning the customer's unstated needs.

You can see how this is strongly analogous to the first step of deliberate practice. It isn't precisely the same; you are not designing a practice activity, but rather doing whatever the requirements of work may demand of you that day. But within that activity, the best performers are focused on how they can get better at some specific element of the work, just as a pianist may focus on improving a particular passage.

With a goal set, the next prework step is planning how to reach the goal. Again, the best performers make the most specific, technique-oriented plans. They're thinking of exactly, not vaguely, how to get to where they're going. So if their goal is discerning the customer's unstated needs, their plan for achieving it on that day may be to listen for certain words the customer might use, or to ask specific questions to bring out the customer's crucial issues.

An important part of prework self-regulation centers on attitudes and beliefs. You may be thinking that figuring out specific goals and plans for what you'll be doing every day sounds hard. It is, and doing it consistently requires high motivation. Where does it come from? The best performers go into their work with a powerful belief in what researchers call their self-efficacy - their ability to perform. They also believe strongly that all their work will pay off for them.


During the work.

The most important self-regulatory skill that top performers use during their work is self-observation. For example, ordinary endurance runners in a race tend to think about anything other than what they're doing; it's painful, and they want to take their minds off it. Elite runners, by contrast, focus intensely on themselves; among other things, they count their breaths and simultaneously count their strides in order to maintain certain ratios.

Most of us don't do work with a significant physical element, but the same principle applies in purely mental work. The best performers observe themselves closely. They are in effect able to step outside themselves, monitor what is happening in their own minds, and ask how it's going. Researchers call this metacognition - knowledge about your own knowledge, thinking about your own thinking. Top performers do this much more systematically than others do; it's an established part of their routine.

Metacognition is important because situations change as they play out. Apart from its role in finding opportunities for practice, it plays a valuable part in helping top performers adapt to changing conditions. When a customer raises a completely unexpected problem in a deal negotiation, an excellent businessperson can pause mentally and observe his or her own mental processes as if from outside: Have I fully understood what's really behind this objection? Am I angry? Am I being hijacked by my emotions? Do I need a different strategy here? What should it be?

In addition, metacognition helps top performers find practice opportunities in evolving situations. Such people can observe their own thinking and ask: What abilities are being taxed in this situation? Can I try out another skill here? Could I be pushing myself a little further? How is it working? Through their ability to observe themselves, they can simultaneously do what they're doing and practice what they're doing.


After the work.

Practice activities are worthless without useful feedback about the results. Similarly, the practice opportunities that we find in work won't do any good if we don't evaluate them afterward. These must be self-evaluations; because the practice activities took place in our own minds, only we can know fully what we were attempting or judge how it turned out.

Excellent performers judge themselves differently from the way other people do. They're more specific, just as they are when they set goals and strategies. Average performers are content to tell themselves that they did great or poorly or okay. The best performers judge themselves against a standard that's relevant for what they're trying to achieve. Sometimes they compare their performance with their own personal best; sometimes they compare with the performance of competitors they're facing or expect to face; sometimes the compare with the best known performance by anyone in the field. Any of those can make sense; the key, as in all deliberate practices, is to choose a comparison that stretches you just beyond your current limits. Research confirms what common sense tells us, that too high a standard is discouraging and not very instructive, while too low a standard produces no advancement.

If you were pushing yourself appropriately and have evaluated yourself rigorously, then you will have identified errors that you made. A critical part of self-evaluation is deciding what caused the errors. Average performers believe their errors were caused by factors outside their control: My opponent got lucky; the task was too hard; I just don't have any natural ability for this. Top performers, by contrast, believe they are responsible for their errors. Note that this is not just a difference of personality or attitude. Recall that the best performers have set highly specific, technique-based goals and strategies for themselves; they have thought through exactly how they intend to achieve what they want. So when something doesn't work, they can relate the failure to specific elements of their performance that may have misfired. Research on champion golfers, for example, has uncovered precisely this pattern. They're much less likely than average golfers to blame their problems on the weather, the course, or chance factors. Instead they focus relentlessly on their own performance.

The final element of the postwork phase is affected by all the others and affects them in turn. You've been through some kind of work experience - a meeting with your team, a trading session, a quarterly budget review, a customer visit. You had thought about what you wanted to achieve and to improve, ant it went however it went. Now: How do you respond? Odds are strong that the experience wasn't perfect, that parts of it were unpleasant. In those cases, excellent performers respond by adapting the way they act; average performers respond by avoiding those situations in the future. That stands to reason. Average performers go into a situation with no clear idea of how they intend to act or how their actions would contribute to reaching their gols. So when things don't turn out perfectly, they attribute the problems to vague forces outside their control. As a result, they are clueless about how to adapt and perform better next time. Little wonder that they'd rather just avoid going through anything like it again, which of course means they have zero chance of getting any better.

Since excellent performers go through a sharply different process from the beginning, they can make good guesses about how to adapt. That is, their ideas for how to perform better next time are likely to work. So it's hardly surprising that they are more likely than average performers to repeat the experience rather than avoid it. And when they do repeat it, we can now understand why they go into it with some of the prework traits and attitudes we observed: They approach the job with more specific goals and strategies, since their previous experience was essentially a test of specific goals and strategies; and they're more likely to believe in their own efficacy because their detailed analysis of their own performance is more effective than the vague, unfocused analysis of average performers. Thus their well-founded belief in their own effectiveness helps give them the crucial motivation to press on, powering a self-reinforcing cycle.


Notes

Yellow: key points
Green: summary statement
Blue: summary story - it explains why deliberate practice matters

Monday, May 14, 2012

Abstraction

We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called "abstraction"; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.
Edsger W. Dijkstra

Wednesday, September 14, 2011

Agile non-negotibles

Agile non-negotiables are those software engineering practices that you'd be crazy to go without.

Unit Testing: Knowing your code works
Refactoring: Paying down your Technical Debt
Test-Driven Development: Knowing what your Goal is before Coding
Pair Programming: Tightly binding review and development together
Continuous Integration: Making it Production Ready

I'm a little crazy. I don't always use all of the above practices. I try to but my desire to be a hero and get things done quickly overcomes my sensible side. I think most people do this too. There are always outside influences that can seduce a developer into over promising.

The argument for ignoring those outside influences and always practicing the above agile non-negotibles is that you will have:
- better quality code,
- more consistent deliveries, and
- less bugs.

Stop worrying about taking three days to develop something that might have took two days had you left out unit testing or refactoring. That is only a short term savings. Consider how long it will take to fix a missed bug or add a new feature next year.

Using the above practices is an investment in the future of your software.

Sunday, September 11, 2011

Pair Programming

I'm a big fan of pair programming. I have used it many times and almost everytime the result was better code that was developed faster. Pair programming is like having continuous code review.

Sadly, there is a lot of controversy with this particular agile/XP practice. Seeing two valuable resources sitting down at one computer makes most managers nervous. They think their team's productivity has just been halved. The worst thing about this mentality is that it makes it clear that the manager thinks programming is just typing.

Mere typing, programming is not. A good idea or a bug caught early on in the process can save a team a lot of work and rework later. By pairing you share valuable knowledge and practices throughout the team, catching more bugs early, and increasing code quality.

Monday, August 15, 2011

Merciless Refactoring

Many people are afraid to make code changes out of fear that they will break the code. To ensure you can safely make code changes you should change it often. I'm not talking about pointless changes but solid improvements. Run FindBugs against your code and fix the issues. If you disagree with FindBugs then use PMD or any static analysis tool. However, if static analysis suggests that your code looks like a bug then consider changing it to look less dangerous.

Anyway, the point of merciless refactoring is to always be improving your code. To make changes and ensure that it was easy to make those changes. If it isn't fast and easy then you need to make changes to make it fast and easy. Write unit tests, delete unused code, optimize loops, automate tests; everything you can do to make it possible to complete your next project in record time.

Merciless refactoring can also be described as following the boy scouts rule of always leaving a place cleaner than when you found it. If you add a method to a class then add some JavaDocs to the other methods while you're there. If you change a single line of code in a method, take a look at the entire class and fix it up if you can.

Thursday, June 02, 2011

HIV/AIDS Cure Proof of Concept

New York magazine had this great article, "The Man Who Had HIV and Now Does Not", last month. It is as the title says about a man who was cured of HIV. It is an amazing read. It is not a cure for everyone; there are some specific genetics required but it is sparking new AIDS research.

Tuesday, November 23, 2010

Secret Santa

I wrote a little webapp to create secret Santa lists:
http://secret-santa-list.appspot.com/

It has a nifty feature that allows you to specify who to exclude as a possible choice for certain people when generating the list. In my case, I used it to generate a list for extended family where spouses did not get each other as secret Santas. Using the exclude list you could also set up a list to ensure that men get gifts for men and women get gifts for women.

For those who are concerned about sending the email addresses of their friends and family across the Internet there is a HTTPS link:
https://secret-santa-list.appspot.com/

Tuesday, November 03, 2009

New Nutrition Goals for dailyburn.com

If you are not happy with dailyburn's suggested nutritional goals because you find them to be too heavy on protein and unrealistic for carbs then you might want to try calculating your goals based on the formulas below.

I've decided on a target of 1900 calories. Since I am not an the Atkins diet which dailyburn seems to be pimping I've done some of my own calculations to adjust my nutritional goal ranges.

First, I used dailyburn as a baseline writing down the suggested values and calculating the differences of each range. Second, I found recommended targets that I am happy with. Finally, I adjusted the values:
  1. With a target of 1900 I used the same range difference that dailyburn used, a difference of 250; giving me a range of 1775 - 2025.
  2. The carb target can be calculated by multipyling 0.125 times your target calories which gave me 238 g [1]. Using dailyburn's difference of 84 that gives me a range of 196 - 280.
  3. I used dailyburn's earlier suggestion to calculate the following ratio: 0.02613. Multiply that by your target calories to get your fat target. Using dailyburn's difference of 29 I get a range of 35 - 64.
  4. For an absolute minimum protein target you should calculate that off the USFDA's recommend value of 50 g per 2000 Cal [2]. I decided to use 1.5 times my weight in Kg as the upper limit; 152 [3]. Then using dailyburn's difference I got a range of 60 - 152.
[1] I picked this because it seems more realistic for my habits.