Models | Examples |
---|---|
Display ads | Yahoo! |
Search ads |
h1. The Plan | |
The plan is to make the next generation of WebCore into something greater -- something beyond the current web frameworks. Something that web functionality is just one part of. A service component framework that facilitates modularity and code reuse. | |
h1. Sources of Inspiration | |
Some existing projects can be used as sources of inspiration for the design of this component framework. Those include: | |
* "Jenkins":http://jenkins-ci.org/ for its web interface and plugin system | |
* "Mule":http://www.mulesoft.org/ and "Apache ServiceMix":https://servicemix.apache.org/ as the leading open source ESBs in the world |
""" | |
The MIT License (MIT) | |
Copyright (c) 2011 Numan Sachwani | |
Permission is hereby granted, free of charge, to any person obtaining a copy of | |
this software and associated documentation files (the "Software"), to deal in | |
the Software without restriction, including without limitation the rights to | |
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies | |
of the Software, and to permit persons to whom the Software is furnished to do | |
so, subject to the following conditions: |
Using Python's built-in defaultdict we can easily define a tree data structure:
def tree(): return defaultdict(tree)
That's it!
packs = None | |
if hasattr(dmd, 'ZenPackManager'): | |
packs = dmd.ZenPackManager.packs | |
else: | |
packs = dmd.packs | |
phase2 = False | |
for pack in packs(): | |
try: |
############################################################################## | |
# | |
# Copyright (C) Zenoss, Inc. 2012, all rights reserved. | |
# | |
# This content is made available according to terms specified in | |
# License.zenoss under the directory where your Zenoss product is installed. | |
# | |
############################################################################## | |
''' |
#System Design Cheatsheet
Picking the right architecture = Picking the right battles + Managing trade-offs
##Basic Steps
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
How do you send information between clients and servers? What format should that information be in? What happens when the server changes the format, but the client has not been updated yet? What happens when the server changes the format, but the database cannot be updated?
These are difficult questions. It is not just about picking a format, but rather picking a format that can evolve as your application evolves.
By now there are many approaches to communicating between client and server. These approaches tend to be known within specific companies and language communities, but the techniques do not cross borders. I will outline JSON, ProtoBuf, and GraphQL here so we can learn from them all.