ACSIC Speaker Series #6 by Prof. Yuanyuan Zhou from UCSD (In Chinese)

Prof. Yuanyuan Zhou’s talk on her startup experience. Although the talk is in Chinese, most of the slides are still in English. Below is the brief intro for the talk.

In this talk, I will share with everyone about the challenges and lessons of starting companies from academia. I have co-founded companies either as a fresh Ph.D graduate (my first startup), and also as a professor (my second and third startup). I have learned many valuable lessons along the way and have also learned a lot from my advisor and many other mentors in entrepreneurship. Moreover, I will also share with everyone some of the logistics such as IP issues with universities, visa problems for your co-founders or early employees, fund raising, etc. At the end, I will also invite two founding members from my current company (one is my former Ph.D student who had a very strong publication record, and the other is a Ph.D graduate from a famous architecture professor at UIUC also with a strong publication record) to share with everyone why they chose to join a startup and what they have learned so far from the startup. So feel free to invite your own Ph.D students or postdoc, too.

Bio: Yuanyuan Zhou is a Qualcomm Chair Professor in Mobile Computing at University of California, San Diego (UCSD) since 2009. Prior to UCSD, she was a tenured professor at University of Illinois, Urbana-Champaign (UIUC). Her area of expertise include data centers, computer systems, data analytics and mobile systems. She has so far graduated 18 Ph.D students, most of whom are now either successful entrepreneurs or tenured/tenure-track professors at top universities including University of Chicago, University of Toronto, University of Waterloo, Ohio State University, etc. In parallel to her academic career, she has also co-founded three companies, with the first two successfully exited to public companies. As the President in her second startup, Pattern Insight, she led the company to become profitable since 2010 and was acquired by VmWare in July 2012, providing good returns for investors and shareholders. Currently she is busy with her third startup, Whova. It has gained substantial customer traction worldwide and has successfully raised substantial investment last year. She obtained her BS in computer science from Peking University, and her MS and Ph.D from Princeton University. She is an ACM Fellow and IEEE Fellow, Sloan Research Fellow (2007) and the winner of ACM Mark Weiser award (2015).

Subtle signal-delivery behavior on OS X (and some other BSD systems)

An online article discussed a subtle behavior on OS X, NetBSD, and OpenBSD delivering the SIGPROF signal to multithreaded programs: http://research.swtch.com/macpprof. In a nutshell, the current implementations in those systems cannot do it right to deliver the signal to a running thread, which most other systems would do.

This behavioral difference affects profilers that rely on SIGPROF to avoid sampling bias. For example, we can see a short description here: https://code.google.com/p/lightweight-java-profiler/issues/detail?id=2.

If the Photos app for Mac stuck on “Updating”…

If you have enabled iCloud Photo Library, and just restored your whole system from a Time-Machine backup, you would very likely see your Photos app keeps showing “Updating”, and you would not see anything in your shared albums (that’s what my system encountered). In the Console, you may see an error log message following a message of “New connection request” from cloudphotosd. The error message shows “RDErrorServiceDatabaseOpenError”.

In that case, delete the directory “~/Library/Containers/com.apple.cloudphotosd/Data/Library/Application Support/com.apple.cloudphotosd/” to force the Photos and its backend services to rebuild the internal database.

Office 2016 for Mac is finally coming (partially) …

Microsoft has finally announced its *preview* version of Office 2016 for Mac. Remember the latest major version for Mac is still 2011; meanwhile, Windows has received two major version updates in the past five years… I almost believed Mac users had been forgotten by Microsoft.

There is a noticeable change on the naming convention: from previous Office for Mac [year] to Office [year] for Mac. It may be a sign that future Office releases are going to be synchronized on all platforms.

Go http://blogs.office.com/2015/03/05/office-2016-mac-preview/ and have a try!

From the name of Windows 10 to crappy software code

There is a rumor on the reason that Microsoft used the name Windows 10 instead of Windows 9: some lazy programmers used to use something like “osName.startsWith(“Windows 9″)” to determine if the current system is Windows 9x (for both Windows 95 and 98). If the new Windows was named after 9, such legacy software would be broken.

Here is a Reddit post discussing the rumor: http://redd.it/2i14ny, funny to read.

It seems that some programming frameworks, such as Java runtime libraries, do provide an easy way to determine OS versions, instead of the Windows API GetVersionEx returning some version numbers. In Java, one can use “System.getProperty(“os.name”)” to get a real OS product name represented in strings, and try doing “startsWith(“Windows 9″)” effectively leading to crappy problems in future.

Regardless of the truth of this rumor, programmers shall never make improper assumptions when writing their code: if you want Windows 98, then use “Windows 98”, and never assume that Microsoft will not announce a new Windows called “Windows 9-is-back”.

Windows 10: April Fool’s Joke Became True

Last year, there was an April Fool’s story saying that Microsoft decided to skip Windows 9, and jumped to Windows 10 directly (see here).

Today, Microsoft announced Windows 10… Facts are sometimes stranger than fictions, indeed.

[2014/09/30 2:00PM] The Windows 10 event is still running. Follow http://live.theverge.com/microsoft-windows-9-event-live-blog/.

Be aware of CVE-2014-6271

CVE-2014-6271, a security vulnerability regarding remote code execution through bash, was disclosed on 9/24/2014. This vulnerability may potentially cause many breaches, due to its low difficulty of being exploited, and the wide use of bash in many CGI and SSH environments. Please see the following links for the detail and the patch information.

http://seclists.org/oss-sec/2014/q3/649
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

P.S., GNU should really work hard on the software security…

The adorable side of Python

Personally I would not consider Python as my first preference to build a complex system. The most important reason is the lack of type checking, so it likely causes some inter-component problems not to manifest until the system is actually running. In addition, if you make some syntactic mistakes such as mistyping variable names, then good luck… You definitely know how annoying it is to debug those problems.

On the other hand, if there is a system written in Python, and you need to do some deep analysis on it, you will probably appreciate those developers who decided to use Python in the first place.

Recently I have been doing some analysis for OpenStack, which is a very popular open-source cloud system, and yes, it is written in Python. So why does Python become so adorable when you analyze a complex system? My answer is Decorators.

Python Decorators really make tasks of instrumentation and interception way easier than in other programming languages. Now I can just insert a simple annotation to some target places in the OpenStack source code via sed, and do a lot of amazing stuff without changing the original source code too much. For instance, it is quite easy to extract communication flows among OpenStack components by decorating communication modules.

The idea of Decorators sourced from the aspect-oriented programming (AOP), and with the dynamism of Python, it becomes easier to implement. Traditionally, if you want to implement Decorators in C# or Java, you will be facing a quite heavy task – which involves writing a bunch of proxy classes, interfaces, and everything else you need to implement the classic factory pattern and the decorator pattern. These patterns are pretty elegant, but too heavy for most scenarios. In contrast, with the ability of meta-programming provided by Python, you can directly modify classes and functions at runtime, and do the magic behind those simple annotations without defining additional classes and interfaces.

There are multiple ways to implement Decorators in Python. Let’s use the following simple and classic example to show some typical implementations.

@class_dec
class Dummy(object):
    def __init__(self, name='World'):
        self.name = name
    @func_dec
    def hello(self):
        print "Hello %s!" % self.name

There are two Decorators here: @class_dec for the class Dummy, and @func_dec for the function hello. Let’s start from implementing @func_dec.

We can do @func_dec in either a class or a function, depending on personal favorites:

""" Implement @func_dec using a class. """
class func_dec(object):
    def __init__(self, fn):
        self.fn = fn
    def __call__(self, inst):
        # Do whatever you want before and after the real function call.
        self.fn(inst)
    def __get__(self, inst, insttype):
        def function(*args, **kwargs):
            self.fn(inst, *args, **kwargs)
        return function

Some people may prefer the above implementation simply because it looks more understandable in an object-oriented fashion. The decoration is mostly done by overriding __call__ and __get__. However, the complexity here is about the “self” object, which is actually referred to different objects in the contexts of Dummy and func_dec. That is why we need __get__ to ensure the method hello receives the correct object.

If you feel dizzy on the above implementation, just try understand the one below, which is purely functional, nice and simple.

""" Implement @func_dec using a function. """
def func_dec(fn):
    def function(self):
        """ Do whatever you want. """
        fn(self)
    return function

To implement @class_func, a nice solution would be the one below:

""" Implement @class_dec using class inheritance. """
def class_dec(cls):
    class NewClass(cls):
        def hook(self):
            """ Do whatever you want. """
            self.name = "Lester"
        def hello(self):
            self.hook()
            super(NewClass, self).hello()
    return NewClass

Looks interesting, right? Actually there could be more ways to implement Decorators. In future posts, I plan to demonstrate some solutions on instrumenting OpenStack.