mo.js is a powerful motion graphics library for the web.
Features:
There's a great Silicon Valley scene in which the Pied Piper team visits another startup's offices. The startup has just gotten an infusion of VC money–which is pretty obvious, thanks to their sleek office, snooty secretary, and rows of fancy drinks.
"We get it, you're funded!" yells one of the Pied Piper guys irately.
This scene is both hilarious and accurate: there are a ton of companies running around with money to spare, in part because it has become much easier to get early stage capital.
[author_more]
But not every business takes outside investment. You can choose to "bootstrap it," or
self-fund your startup. That means relying on savings, credit cards, side jobs, and sweat equity.
It also probably means no fancy coconut water.
Trying to decide whether or not to bootstrap? Here's what you need to know.
Let's start with the obvious: when you bootstrap, you retain 100% of your company.
That means you have complete control over your startup's mission, product, and team. If you accept venture capital, on the other hand, you'll be answering to your investors–and most have strong opinions about how you should do things.
It also means you'll be on a timeline. Every VC is looking for that 10X (or better) return, and they want it as soon as possible. That also means they want you to start spending their money right away, and specifically on measures that'll make you grow more rapidly. The "slow and steady" strategy is definitely not compatible with the VC's approach; entrepreneurs who'd rather control their own growth rate should consider self-funding.
Bootstrapping also keeps you scrappy. Since you don't have the luxury of spending a single extra cent, you're forced to pay hawk-like attention to your operating costs and revenue. You'll become as efficient and resourceful as possible.
And, on a related note, bootstrapping also makes you more creative. If you've got a $4,000 marketing budget, as opposed to a $40,000 marketing budget, you'll think much more carefully about how to promote your startup for free.
Seeking investments also takes a lot of time. Instead of working with your team, you're out networking with investors, putting together pitch decks, practicing your elevator speech, actually giving those presentations, and sending email after email. It's an exhausting, multi-month process, and the odds are, most VCs you're meeting with are going to pass.
Final reason to consider self-funding: just because you don't raise now doesn't mean you can never raise. If you can achieve profitability on your own, you'll be a very attractive investment–not only will you have proven traction, but investors will be able to get in on a later-stage opportunity without the standard dilution.
Let's say you've got a really unique product idea. You decide to bootstrap, so it takes you half a year to go to market. In that time, two other companies enter the space with similar products, and you lose your competitive advantage.
Yeah–you probably should've acquired VC funding.
Or maybe you've got a really unique product idea that will someday generate a lot of revenue, but not before swallowing a ton of money. Companies in this category include Facebook, Snapchat, Dropbox, and Evernote.
Generally, the startups that should seek VC money are in tech and/or new or emerging industries.
VC funding also comes with another bonus. When you need advice or feedback from someone who's likely dealt with tens or even hundreds of companies, your investors are eager to help. Furthermore, if you need connections to other influential people, they can make the intro or at least give you some insight.
And having a well-respected VC back you does enormous things for your credibility. If you're trying to hire an in-demand engineer, saying, "Andreessen Horowitz is one of our investors," would definitely get his or her attention.
Unlike many VC-funded startups, who have the luxury of building a huge audience or customer base before monetizing them (cough, Instagram, Postmates, Luxe), you need to focus on profitability from the get-go.
Guy Kawasaki, a well-known entrepreneurship expert, says concentrating on cash flow is even more important. In other words, if you're choosing between a $20,000 sale that'll take a year to close and a $5,000 sale that'll take two months, go for the latter–because your electric bill is due in 15 days.
If you can, Kawasaki says to establish a short sales cycle, short payment terms, and recurring revenue.
You should also create a minimum viable product as soon as possible. And get creative! Jason Boehmig wanted to develop a software platform that would enable businesses to automate routine legal paperwork. In the beginning, he sold customers "software" while actually doing the work himself behind-the-scenes.
Not only did this technique validate his idea, it also allowed him to use the money from his first sales to build his actual product. (Check out six more unique ways to build an MVP.)
Continue reading %Bootstrapping 101: How (and Why) to Self-Fund Your Startup%
AngularJS offers many different options to use the publish-subscribe pattern through three different "watch" methods. Each of them takes optional parameters that can modify its behavior.
The official documentation on $watch is anything but thorough: a problem that has afflicted AngularJS v1 as whole, after all.
And even online resources explaining how to proceed are, at best, scattered.
So, in the end, it becomes hard for developers choosing the right method for a given situation. And that's especially true for AngularJS beginners! Results can be surprising or unpredictable, and this inevitably leads to bugs.
In this article I will assume some familiarity with AngularJS concepts. If you feel you need a refresher, you might want to read up on $scope, binding and $apply and $digest.
For example, what's the best way to watch the first element of an array?
Suppose we have an array declared on our scope, $scope.letters = ['A','B','C'];
$scope.$watch('letters', function () {...}); fire its callback when we add an element to the array?$scope.$watch('letters[0]', function () {...});? Will it work the same, or better?$watch, $watchCollection, and $watchGroup?If you feel confused by all these questions, please keep reading. My aim is to make this as clear as possible through several examples, guiding you along the way.
Let's start with $scope.$watch. This is the workhorse of all the watch functionality: every other method we will see is just a convenient shortcut for $watch.
Now, what's great about Angular is that you can use the same mechanism explicitly to perform complex actions in your controllers triggered by data changes. For instance, you could set a watcher on some data that can change in response to:
You can just set up a single listener to handle any data change, no matter what caused it.
To do so, however, you need to call $scope.$watch yourself.
Let's take a look at the code for $rootscope.watch().
This is its signature: function(watchExp, listener, objectEquality, prettyPrintExpression).
In details, its four parameters:
watchExp The expression being watched. It can be a function or a string, it is evaluated at every digest cycle.
One key aspect to note here, is that if the expression is evaluated as a function, then that function needs to be idempotent. In other words, for the same set of inputs it should always return the same output. If this is not the case, Angular will assume that the data being watched has changed. In turn, this means that it will keep detecting a difference and call the listener at every iteration of the digest cycle.
listener A callback, fired when the watch is first set, and then each time that during the digest cycle that a change for watchExp's value is detected. The initial call on setup is meant to store an initial value for the expression.
objectEquality If, and only if, this is true the watcher will perform a deep comparison. Otherwise it performs a shallow comparison, i.e. only the references will be compared.
Let's take an array as an example: $scope.fruit = ["banana", "apple"];.
objectEquality == false means that only a reassignment to the fruit field will yield a call to the listener.
We also need to check "how deep" is a deep comparison: we'll look at that later.
prettyPrintExpression
If passed, it overrides the watch expression. This parameter is NOT meant to be used in normal calls to $watch(); it is used internally by expression parser.
Be careful: as you can see for yourself, it's very easy to run into unexpected results when passing a 4th parameter by mistake.
Continue reading %Mastering $watch in AngularJS%
Gone are the days when WordPress was referred to as just blogging software.
The ability to extend its functionality via plugins and themes, group posts or structured data into various types and also the arrival of the WP Rest API into core, has seen it further evolve into a full blown content management system and development platform.
Over the years, I have successfully developed a number of custom web applications built on-top WordPress that heavily utilize custom post types. An example of one of these web applications is the theme marketplace of my WordPress plugin called ProfilePress.
On a closer look at the theme marketplace linked above, you will discover that it uses a custom pagination system evident in the URL of the Next / Prev pagination links. Thus, it is possible for you to build an in-house pagination system that will work perfectly in querying a custom post type (CPT).
Enough said, let’s get down to the purpose of this tutorial which is, learning the intricacies of custom post types in WordPress.
I hope to address the many hurdles I have personally encountered working with CPTs as well as some cool stuff you can do with it.
Continue reading %The Definitive Guide to WordPress Custom Post Types%
Spending time to develop and app that is accessible to all is an important task to empower potential users.
Android has built in accessibility features to help users who interact with their devices in different ways. These include autocomplete, a screen reader (TalkBack) and Text-to-speech output. So why create your own custom accessibility service?
Making your own accessibility service allows you to customize an app for a specific group of users that suits your app.
Continue reading %Inclusive Android Interfaces with Custom Accessibility Services%
Python 3.5 introduced the new typing module that provides standard library support for leveraging function annotations for optional type hints. That opens the door to new and interesting tools for static type checking like mypy and in the future possibly automated type-based optimization. Type hints are specified in PEP-483 and PEP-484.
In this tutorial I explore the possibilities that type hints present and show you how to use mypy to statically analyze your Python programs and significantly improve the quality of your code.
Type hints are built on top of function annotations. Check out Python 3 Function Annotations for a detailed deep dive into function annotations. Briefly, function annotations let you annotate the arguments and return value of a function or method with arbitrary metadata. Type hints are a special case of function annotations that specifically annotate function arguments and the return value with standard type information. Function annotations in general and type hints in particular are totally optional. Let’s take a look at a quick example:
def reverse_slice(text: str, start: int, end: int) -> str:
return text[start:end][::-1]
reverse_slice('abcdef', 3, 5)
'ed'
The arguments were annotated with their type as well as the return value. But it’s critical to realize that Python ignores this completely. It makes the type information available through the annotations attribute of the function object, but that’s about it.
reverse_slice.__annotations
{'end': int, 'return': str, 'start': int, 'text': str}
To verify that Python really ignores the type hints, let’s totally mess up the type hints:
def reverse_slice(text: float, start: str, end: bool) -> dict:
return text[start:end][::-1]
reverse_slice('abcdef', 3, 5)
'ed'
As you can see, the code behaves the same, regardless of the type hints.
OK. Type hints are optional. Type hints are totally ignored by Python. What’s the point of them, then? Well, there are several good reasons:
I’ll dive into static analysis with Mypy later. IDE support already started with PyCharm 5’s support for type hints. Standard documentation is great for developers that can easily figure out the type of arguments and return value just by looking at a function signature as well as automated documentation generators that can extract the type information from the hints.
typing ModuleThe typing module contains types designed to support type hints. Why not just use existing Python types like int, str, list and dict? You can definitely use these types, but due to Python’s dynamic typing, beyond basic types you don’t get a lot of information. For example, if you want to specify that an argument may be a mapping between a string and an integer, there is no way to do it with standard Python types. With the typing module, it’s as easy as:
Mapping[str, int]
Let’s look at a more complete example: a function that takes two arguments. One of them is a list of dictionaries where each dictionary contains keys that are strings and values that are integers. The other argument is either a string or an integer. The typing module allows precise specifications of such complicated arguments.
from typing import List, Dict, Union
def foo(a: List[Dict[str, int]],
b: Union[str, int]) -> int:
"""Print a list of dictionaries and return the number of dictionaries
"""
if isinstance(b, str):
b = int(b)
for i in range(b):
print(a)
x = [dict(a=1, b=2), dict(c=3, d=4)]
foo(x, '3')
[{'b': 2, 'a': 1}, {'d': 4, 'c': 3}]
[{'b': 2, 'a': 1}, {'d': 4, 'c': 3}]
[{'b': 2, 'a': 1}, {'d': 4, 'c': 3}]
Let’s see some of the more interesting types from the typing module.
The Callable type allows you to specify the function which may be passed as arguments or returned as a result, since Python treats functions as first-class citizens. The syntax for callables is to provide an array of argument types (again from the typing module) followed by a return value. If that’s confusing, here is an example:
def do_something_fancy(data: Set[float], on_error: Callable[[Exception, int], None]):
...
The on_error callback function is specified as a function that takes an Exception and an integer as arguments and returns nothing.
The Any type means that a static type checker should allow any operation as well as assignment to any other type. Every type is a subtype of Any.
The Union type you saw earlier is useful when an argument can have multiple types, which is very common in Python. In the following example, the verify_config() function accepts a config argument, which can be either a Config object or a file name. If it’s a file name, it calls another function to parse the file into a Config object and return it.
def verify_config(config: Union[str, Config]):
if isinstance(config, str):
config = parse_config_file(config)
...
def parse_config_file(filename: str) -> Config:
...
The Optional type means the argument may be None too. Optional[T] is equivalent to Union[T, None]
There are many more types that denote various capabilities such as Iterable, Iterator, Reversible, SupportsInt, SupportsFloat, Sequence, MutableSequence and IO. Check out the typing module documentation for the full list.
The main thing is that you can specify the type of arguments in a very fine-grained way that supports the Python type system at a high fidelity and allows generics and abstract base classes too.
Sometimes you want to refer to a class in a type hint within one of its methods. For example, let’s assume that class A can perform some merge operation that takes another instance of A, merges with itself and returns the result. Here is a naive attempt to use type hints to specify it:
class A:
def merge(other: A) -> A:
...
1 class A:
----> 2 def merge(other: A = None) -> A:
3 ...
4
NameError: name 'A' is not defined
What happened? The class A is not defined yet when the type hint for its merge() method is checked by Python, so the class A can’t be used at this point (directly). The solution is quite simple, and I’ve seen it used before by SQLAlchemy. You just specify the type hint as a string. Python will understand that it is a forward reference and will do the right thing:
class A:
def merge(other: 'A' = None) -> 'A':
...
One downside of using type hints for long type specifications is that it can clutter the code and make it less readable, even if it provides a lot of type information. You can alias types just like any other object. It’s as simple as:
Data = Dict[int, Sequence[Dict[str, Optional[List[float]]]]
def foo(data: Data) -> bool:
...
get_type_hints() Helper FunctionThe typing module provides the get_type_hints() function, which provides information about the argument types and the return value. While the annotations attribute returns type hints because they are just annotations, I still recommend that you use the get_type_hints() function because it resolves forward references. Also, if you specify a default of None to one of the arguments, the get_type_hints() function will automatically return its type as Union[T, NoneType] if you just specified T. Let’s see the difference using the A.merge() method defined earlier:
print(A.merge.__annotations__)
{'other': 'A', 'return': 'A'}
The annotations attribute simply returns the annotation value as is. In this case it’s just the string ‘A’ and not the A class object, to which ‘A’ is just a forward reference.
print(get_type_hints(A.merge))
{'return': <class '__main__.A'>, 'other': typing.Union[__main__.A, NoneType]}
The get_type_hints() function converted the type of the other argument to a Union of A (the class) and NoneType because of the None default argument. The return type was also converted to the class A.
Type hints are a specialization of function annotations, and they can also work side by side with other function annotation.
In order to do that, the typing module provides two decorators: @no_type_check and @no_type_check_decorator. The @no_type_check decorator can be applied to either a class or a function. It adds the no_type_check attribute to the function (or each method of the class). This way, type checkers will know to ignore annotations, which are not type hints.
It is a little cumbersome because if you write a library that will be used broadly, you must assume that a type checker will be used, and if you want to annotate your functions with non-type hints, you must also decorate them with @no_type_check.
A common scenario when using regular function annotations is also to have a decorator that operates over them. You also want to turn off type checking in this case. One option is to use the @no_type_check decorator in addition to your decorator, but that gets old. Instead, the @no_Type_check_decorator can be used to decorate your decorator so that it also behaves like @no_type_check (adds the no_type_check attribute).
Let me illustrate all these concepts. If you try to get_type_hint() (as any type checker will do) on a function that is annotated with a regular string annotation, the get_type_hints() will interpret it as a forward reference:
def f(a: 'some annotation'):
pass
print(get_type_hints(f))
SyntaxError: ForwardRef must be an expression -- got 'some annotation'
To avoid it, add the @no_type_check decorator, and get_type_hints simply returns an empty dict, while the __annotations__ attribute returns the annotations:
@no_type_check
def f(a: 'some annotation'):
pass
print(get_type_hints(f))
{}
print(f.__annotations__)
{'a': 'some annotation'}
Now, suppose we have a decorator that prints the annotations dict. You can decorate it with the @no_Type_check_decorator and then decorate the function and not worry about some type checker calling get_type_hints() and getting confused. This is probably a best practice for every decorator that operates on annotations. Don’t forget the @functools.wraps, otherwise the annotations will not be copied to the decorated function and everything will fall apart. This is covered in detail in Python 3 Function Annotations.
@no_type_check_decorator
def print_annotations(f):
@functools.wraps(f)
def decorated(*args, **kwargs):
print(f.__annotations__)
return f(*args, **kwargs)
return decorated
Now, you can decorate the function just with @print_annotations, and whenever it is called it will print its annotations.
@print_annotations
def f(a: 'some annotation'):
pass
f(4)
{'a': 'some annotation'}
Calling get_type_hints() is also safe and returns an empty dict.
print(get_type_hints(f))
{}
Mypy is a static type checker that was the inspiration for type hints and the typing module. Guido van Rossum himself is the author of PEP-483 and a co-author of PEP-484.
Mypy is in very active development, and as of this writing the package on PyPI is out of date and doesn’t work with Python 3.5. To use Mypy with Python 3.5, get the latest from Mypy’s repository on GitHub. It’s as simple as:
pip3 install git+git://github.com/JukkaL/mypy.git
Once you have Mypy installed, you can just run Mypy on your programs. The following program defines a function that expects a list of strings. It then invokes the function with a list of integers.
from typing import List
def case_insensitive_dedupe(data: List[str]):
"""Converts all values to lowercase and removes duplicates"""
return list(set(x.lower() for x in data))
print(case_insensitive_dedupe([1, 2]))
When running the program, it obviously fails at runtime with the following error:
python3 dedupe.py
Traceback (most recent call last):
File "dedupe.py", line 8, in <module>
print(case_insensitive_dedupe([1, 2, 3]))
File "dedupe.py", line 5, in case_insensitive_dedupe
return list(set(x.lower() for x in data))
File "dedupe.py", line 5, in <genexpr>
return list(set(x.lower() for x in data))
AttributeError: 'int' object has no attribute 'lower'
What’s the problem with that? The problem is that it’s not clear immediately even in this very simple case what the root cause is. Is it an input type problem? Or maybe the code itself is wrong and shouldn’t try to call the lower() method on the ‘int’ object. Another issue is that if you don’t have 100% test coverage (and, let’s be honest, none of us do), then such issues can lurk in some untested, rarely used code path and be detected at the worst time in production.
Static typing, aided by type hints, gives you an extra safety net by making sure you always call your functions (annotated with type hints) with the right types. Here is the output of Mypy:
(N) > mypy dedupe.py dedupe.py:8: error: List item 0 has incompatible type "int" dedupe.py:8: error: List item 1 has incompatible type "int" dedupe.py:8: error: List item 2 has incompatible type "int"
This is straightforward, points directly to the problem, and doesn’t require running a lot of tests. Another benefit of static type checking is that if you commit to it, you can skip dynamic type checking except when parsing external input (reading files, incoming network requests or user input). It also builds a lot of confidence as far as refactoring goes.
Type hints and the typing module are totally optional additions to the expressiveness of Python. While they may not suit everyone’s taste, for large projects and large teams they can be indispensable. The evidence is that large teams already use static type checking. Now that type information is standardized, it will be easier to share code, utilities and tools that use it. IDEs like PyCharm already take advantage of it to provide a better developer experience.
