Bossie Premios 2011: La mejor aplicación de código abierto de desarrollo de software

Centro de InfoWorld prueba recoge las mejores herramientas de desarrollo de código abierto de 2011

 

 

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

 

Web2py

Cuando Massimo Di Pierro, un profesor de ciencias de la computación en la Universidad DePaul, creado Web2py , fue el objetivo de construir un marco Web basado en Python que era a la vez potente y fácil de usar. Él tuvo éxito. Web2py es un diseño inteligente, bien elaborado marco que cuenta con una pequeña huella, una API ordenado, excelente documentación, y una sopa a las nueces basado en la Web herramienta de administración que también sirve como un entorno de desarrollo integrado completo.La instalación es fácil, los asistentes ayudar a acelerar la creación de nuevas aplicaciones, y la complejidad es una abstracción.Web2py es un marco de gran alcance capaz con un montón de sorpresas agradables debajo de la capilla – un destacado entre lospilares de Python .

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/argee/1001

Introducing Cloud Synchronization in GNU Cash with Google Docs by using Gdata python module.

Rahul Gaur

[ urlimport.py ]
Enables remote module importing through urllib2 and perforce.

author:    Jure Vrscaj <[email protected]>

homepage:  http://urlimport.codeshift.net
download: all the project's files may be downloaded from bitbucket with hg: hg clone http://bitbucket.org/alexbodn/urlimport Usage:  import sys, urlimport urlimport.config(**{     'ssl_key.https://your.url':'key for this url'     'ssl_cert.https://your.url':'cert for this url',     'opener.https://your.url':'opener for this url',     'cache_time.http://your.url':'timedelta to keep files in cache for this url',     'no_cache.url':True, # don't cache modules from this url     'user_agent.url':'user agent header for this url',     'ssl_key.host':'key for this host'     'ssl_cert.host':'cert for this host',     'opener.host':'opener for this host',     'cache_time.host':'timedelta to keep files in cache for this host',     'no_cache.host':True, # don't cache modules from this host     'user_agent.host':'user agent header for this host',     'ssl_key':'key for unspecified urls',     'ssl_cert':'cert for unspecified urls',     'opener':'opener for unspecified urls',     'no_cache':'True, #don't cache modules for unspecified urls     'user_agent':'user agent header for unspecified urls',     'cache_time':'timedelta to keep files in cache for unspecified urls',     #if cache_time is missing, keep forever, but check last_modified and etag     'cache_dir':'root of the cache dir', # if missing, a temp dir will be created,                                         # if empty, no cache will be used     'py_version_string': '$PYTHON_VERSION', # string in path to be replaced by                                             # $major.$minor     'debug': int(level of output text. see debug() function) }) # note: if you supply your own opener, i'd recommand inheriting/implementing the # status handling features from class DefaultErrorHandler below. sys.path.insert(0, "http://your.url") #this may already be there, like setting                                       #PYTHONPATH                                       #but there is a danger default import                                       #would try it before expect to have access to your modules at http://your.url

http://pypi.python.org/pypi/urlimport/

Permitie la importación de archivos a través de la web, mediante la adición de urls a PYTHONPATH

38 Life Lessons I’ve Learned in 38 Years | zen habits

Post written by Leo Babauta.

Today (April 30) I turn 38 years old.

I’ve been on this earth for nearly four decades. Being in a city like Paris, where there are buildings that measure their age by the millennia, helps put that brief blink of the eye into perspective. But still, it amazes me that I’ve been around that long — I feel like I’ve barely begun.

I’m not usually one to make a big deal about my birthday, but as always, it has given me an opportunity to reflect. I thought I’d share a handful of lessons I’ve learned — as a helpful guide for those just starting out.

This post is for my children, whom I miss greatly across the distance of a continent and an ocean. I hope this will shine a dim light on the streets they have to navigate ahead of them, though I know they’ll still stumble as much as I have.

This is for you, Chloe, Justin, Rain, Maia, Seth and Noelle. I apologize for the length.

38 Lessons I’ve Learned in My 38 Years

1. Always swallow your pride to say you’re sorry. Being too proud to apologize is never worth it — your relationship suffers for no good benefit.

2. Possessions are worse than worthless — they’re harmful. They add no value to your life, and cost you everything. Not just the money required to buy them, but the time and money spent shopping for them, maintaining them, worrying about them, insuring them, fixing them, etc.

3. Slow down. Rushing is rarely worth it. Life is better enjoyed at a leisurely pace.

4. Goals aren’t as important as we think. Try working without them for a week. Turns out, you can do amazing things without goals. And you don’t have to manage them, cutting out on some of the bureaucracy of your life. You’re less stressed without goals, and you’re freer to choose paths you couldn’t have foreseen without them.

5. The moment is all there is. All our worries and plans about the future, all our replaying of things that happened in the past — it’s all in our heads, and it just distracts us from fully living right now. Let go of all that, and just focus on what you’re doing, right at this moment. In this way, any activity can be meditation.

6. When your child asks for your attention, always grant it. Give your child your full attention, and instead of being annoyed at the interruption, be grateful for the reminder to spend time with someone you love.

7. Don’t go into debt. That includes credit card debt, student debt, home debt, personal loans, auto loans. We think they’re necessary but they’re not, at all. They cause more headaches than they’re worth, they can ruin lives, and they cost us way more than we get. Spend less than you earn, go without until you have the money.

8. I’m not cool, and I’m cool with that. I wasted a lot of energy when I was younger worrying about being cool. It’s way more fun to forget about that, and just be yourself.

9. The only kind of marketing you need is an amazing product. If it’s good, people will spread the word for you. All other kind of marketing is disingenuous.

10. Never send an email or message that’s unfit for the eyes of the world. In this digital age, you never know what might slip into public view.

11. You can’t motivate people. The best you can hope for is to inspire them with your actions. People who think they can use behavioral “science” or management techniques have not spent enough time on the receiving end of either.

12. If you find yourself swimming with all the other fish, go the other way. They don’t know where they’re going either.

13. You will miss a ton, but that’s OK. We’re so caught up in trying to do everything, experience all the essential things, not miss out on anything important … that we forget the simple fact that we cannot experience everything. That physical reality dictates we’ll miss most things. We can’t read all the good books, watch all the good films, go to all the best cities in the world, try all the best restaurants, meet all the great people. But the secret is: life is better when we don’t try to do everything. Learn to enjoy the slice of life you experience, and life turns out to be wonderful.

14. Mistakes are the best way to learn. Don’t be afraid to make them. Try not to repeat the same ones too often.

15. Failures are the stepping stones to success. Without failure, we’ll never learn how to succeed. So try to fail, instead of trying to avoid failure through fear.

16. Rest is more important than you think. People work too hard, forget to rest, and then begin to hate their jobs. In fitness, you see it constantly: people training for a marathon getting burned out because they don’t know how to let their straining muscles and joints recover. People who try to do too much because they don’t know that rest is where their body gets stronger, after the stress.

17. There are few joys that equal a good book, a good walk, a good hug, or a good friend. All are free.

18. Fitness doesn’t happen overnight. It’s a long process, a learning process, something that happens in little bits over a long period. I’ve been getting fit for five years now, and I still have more to learn and do. But the progress I’ve made has been amazing, and it’s been a great journey.

19. The destination is just a tiny slice of the journey. We’re so worried about goals, about our future, that we miss all the great things along the way. If you’re fixated on the goal, on the end, you won’t enjoy it when you get there. You’ll be worried about the next goal, the next destination.

20. A good walk cures most problems. Want to lose weight and get fit? Walk. Want to enjoy life but spend less? Walk. Want to cure stress and clear your head? Walk. Want to meditate and live in the moment? Walk. Having trouble with a life or work problem? Walk, and your head gets clear.

21. Let go of expectations. When you have expectations of something — a person, an experience, a vacation, a job, a book — you put it in a predetermined box that has little to do with reality. You set up an idealized version of the thing (or person) and then try to fit the reality into this ideal, and are often disappointed. Instead, try to experience reality as it is, appreciate it for what it is, and be happy that it is.

22. Giving is so much better than getting. Give with no expectation of getting something in return, and it becomes a purer, more beautiful act. To often we give something and expect to get an equal measure in return — at least get some gratitude or recognition for our efforts. Try to let go of that need, and just give.

23. Competition is very rarely as useful as cooperation. Our society is geared toward competition — rip each other’s throats out, survival of the fittest, yada yada. But humans are meant to work together for the survival of the tribe, and cooperation pools our resources and allows everyone to contribute what they can. It requires a whole other set of people skills to work cooperatively, but it’s well worth the effort.

24. Gratitude is one of the best ways to find contentment. We are often discontent in our lives, desire more, because we don’t realize how much we have. Instead of focusing on what you don’t have, be grateful for the amazing gifts you’ve been given: of loved ones and simple pleasures, of health and sight and the gift of music and books, of nature and beauty and the ability to create, and everything in between. Be grateful every day.

25. Compassion for other living things is more important than pleasure. Many people scoff at vegetarianism because they love the taste of meat and cheese too much, but they are putting the pleasure of their taste buds ahead of the suffering of other living, feeling beings. You can be perfectly healthy on a vegetarian (even vegan) diet, so killing and torturing animals is absolutely unnecessary. Compassion is a much more fulfilling way to live than closing your eyes to suffering.

26. Taste buds change. I thought I could never give up meat, but by doing it slowly, I never missed it. I thought I could never give up junk food like sweets, fried crap, nachos, all kinds of unhealthy things … and yet today I would rather eat some fresh berries or raw nuts. Weird, but it’s amazing how much our taste buds can change.

27. Create. The world is full of distractions, but very few are as important as creating. In my job as a writer, there is nothing that comes close to being as crucial as creating. In my life, creating is one of the few things that has given me meaning. When it’s time to work, clear away all else and create.

28. Get some perspective. Usually when we’re worried or upset, it’s because we’ve lost perspective. In the larger picture, this one problem means almost nothing. This fight we’re having with someone else — it’s over something that matters naught. Let it go, and move on.

29. Don’t sit too much. It kills you. Move, dance, run, play.

30. Use the magic of compound interest. Invest early, and it will grow as if by alchemy. Live on little, don’t get into debt, save all you can, and invest it in mutual funds. Watch your money grow.

31. All we are taught in schools, and all we see in the media (news, films, books, magazines, Internet) has a worldview that we’re meant to conform to. Figure out what that worldview is, and question it. Ask if there are alternatives, and investigate. Hint: the corporations exert influence over all of our information sources. Another hint: read Chomsky.

32. Learn the art of empathy. Too often we judge people on too little information. We must try to understand what they do instead, put ourselves in their shoes, start with the assumption that what others do has a good reason if we understand what they’re going through. Life becomes much better if you learn this art.

33. Do less. Most people try to do too much. They fill life with checklists, and try to crank out tasks as if they were widget machines. Throw out the checklists and just figure out what’s important. Stop being a machine and focus on what you love. Do it lovingly.

34. No one knows what they’re doing as parents. We’re all faking it, and hoping we’re getting it right. Some people obsess about the details, and miss out on the fun. I just try not to mess them up too much, to show them they’re loved, to enjoy the moments I can with them, to show them life is fun, and stay out of the way of them becoming the amazing people they’re going to become. That they already are.

35. Love comes in many flavors. I love my children, completely and more than I can ever fully understand. I love them each in a different way, and know that each is perfect in his or her own way.

36. Life is exceedingly brief. You might feel like there’s a huge mass of time ahead of you, but it passes much faster than you think. Your kids grow up so fast you get whiplash. You get gray hairs before you’re done getting your bearings on life. Appreciate every damn moment.

37. Fear will try to stop you. Doubts will try to stop you. You’ll shy away from doing great things, from going on new adventures, from creating something new and putting it out in the world, because of self-doubt and fear. It will happen in the recesses of your mind, where you don’t even know it’s happening. Become aware of these doubts and fears. Shine some light on them. Beat them with a thousand tiny cuts. Do it anyway, because they are wrong.

38. I have a lot left to learn. If I’ve learned anything, it’s that I know almost nothing, and that I’m often wrong about what I think I know. Life has many lessons left to teach me, and I’m looking forward to them all.

—
tweet love

Finding the closest data center using GeoIP and indexing

Alon Swartz – Mon, 2010/08/16 – 05:08 – 8 comments

We are about to release the TurnKey Linux Backup and Migration (TKLBAM) mechanism, which boasts to be the simplest way, ever, to backup a TurnKey appliance across all deployments (VM, bare-metal, Amazon EC2, etc.), as well as provide the ability to restore a backup anywhere, essentially appliance migration or upgrade.

Note: We’ll be posting more details really soon – In this post I just want to share an interesting issue we solved recently.

Backups need to be stored somewhere – preferably somewhere that provides unlimited, reliable, secure and inexpensive storage. After exploring the available options, we decided on Amazon S3 for TKLBAM’s storage backend.
 

The problem

Amazon have 4 data centers called regions spanning the world, situated in North California (us-west-1), North Virginia (us-east-1), Ireland (eu-west-1) and Singapore (ap-southeast-1).

 

The problem: Which region should be used to store a servers backups, and how should it be determined?

 

One option was to require the user to specify the region to be used during backup, but, we quickly decided against polluting the user interface with options which can be confusing, and opted for a solution that could automatically determine the best region.

 

The solution

The below map plots the countries/states with their associated Amazon region:

 

Generated automatically using Google Maps API from the indexes.

 

The solution: Determine the location of the server, then lookup the closest Amazon region to the servers location.

 

Part 1: GeoIP

This was the easy part. The TurnKey Hub is developed using Django which ships with GeoIP support in contrib. Within a few minutes of being totally new to geo-location I had part 1 up and running.

 

When TKLBAM is initialized and a backup is initiated, the Hub is contacted to get authentication credentials and the S3 address for backup. The Hub performs a lookup on the IP address and enumerates the country/state.

 

In a nutshell, adding GeoIP support to your Django app is simple: Install Maxmind’s C library and download the appropriate dataset. Then, once you update your settings.py file, you’re all set.

 

settings.py

GEOIP_PATH = "/volatile/geoip"
GEOIP_LIBRARY_PATH = "/volatile/geoip/libGeoIP.so"

code

from django.contrib.gis.utils import GeoIP

ipaddress = request.META['REMOTE_ADDR']
g = GeoIP()
g.city(ipaddress)
    {'area_code': 609,
     'city': 'Absecon',
     'country_code': 'US',
     'country_code3': 'USA',
     'dma_code': 504,
     'latitude': -39.420898,
     'longitude': - 74.497703,
     'postal_code': '08201',
     'region': 'NJ'}

 

Part 2: Indexing

This part was a little more complicated.

 

Now that we have the servers location, we can lookup the closest region. The problem is creating an index of each and every country in the world, as well as each US state – and associating them with their closest Amazon region.

 

Creating the index could have been really pain staking, boring and error prone if doing it manually – so I devised a simple automated solution:

• Generate a mapping of country and state codes with their coordinates (latitude and longitude).
• Generate a reference map of the server farms coordinates.
• Using a simple distance based calculation, determine the closest region to each country/state, and finally output the index files.

I was also planning on incorporating data about internet connection speeds and trunk lines between countries, and add weight to the associations, but decided that was overkill.

 

We are making the indexes available for public use (countries.index, unitedstates.index).

 

More importantly, we need your help to tweak the indexes – as you have better knowledge and experience on your connection latency and speed. Please let us know if you think we should associate your country/state to a different Amazon region.

Enjoyed this post? Get future posts delivered by email or get the RSS feed.
Find us on Facebook and Twitter.

Comments

Map of worldwide underwater cables

Alon Swartz – Mon, 2010/08/16 – 05:38.

I thought I’d post this as reference, seems to correlate quite nicely with the generated indexes.

Source: Greg’s cable map

• reply

That is seriously cool!

Jeremy (aka JedMe… – Mon, 2010/08/16 – 06:22.

Interesting to have a look at where they all go. Thanks for posting Alon!

—

• reply

Australia connecting to Asia’s Amazon servers makes sense.

Jeremy (aka JedMe… – Mon, 2010/08/16 – 06:19.

But does that mean that TKLBAM will only do remote backup/migration to Amazon EC2? Will there be some facility to specify your own remote location? Or even a local location (server or even HDD/etc?

I note that you mention more details to come, so pls feel free to ignore this and make me wait

—

• reply

The default storage backend will be Amazon S3, but…

Alon Swartz – Mon, 2010/08/16 – 06:43.

I won’t ignore you completely, but I will make you wait for the full details. The default storage backend will be Amazon S3, as it provides unlimited, reliable, secure and inexpensive storage.

Did I mention inexpensive? With all our testing we have yet to break the $0.01 barrier. TKLBAM only stores the delta of changes, and performs incremental backups, so space isn’t really an issue (at least for most use cases).

It will be possible to use alternative storage backends, but won’t be officially supported. There are a couple of caveats though, so the user experience won’t be as smooth as using the default backend, but it will be possible.

Detailed information will be posted soon, really soon…

• reply

Is GeoIP going to give you enough information?

Carson McDonald – Tue, 2010/08/17 – 01:57.

This seems interesting but GeoIP data isn’t always that acurate. It seems like a better way of going about this would be to measure actual latency and bandwidth from each location in the same country or a close country. I would imagine using ping and downloading a reasonably large file would do the trick.

• reply

Clarification

Alon Swartz – Tue, 2010/08/17 – 08:48.

I totally agree that basing solely off geographic location is not adequate, so let me clarify the implementation details.

In production, we use GeoIP to determine the country/state of the server in question, and then perform a lookup in the generated indexes to determine the preferred region. I say preferred (and not closest) because the indexes are static, and are not calculated on the fly. This was a design decision to allow us to tweak the indexes with the help of community feedback.

The location based calculation described above was used to generate the baseline indexes to provide a relatively good starting point. One of the reasons for writing this blog post and publishing the indexes, was to take us to the next phase of tweaking the indexes, hence the closing paragraph:

we need your help to tweak the indexes – as you have better knowledge and experience on your connection latency and speed. Please let us know if you think we should associate your country/state to a different Amazon region.

The countries and US indexes consist of 249 and 62 entries, respectively. We don’t have the resources to perform latency testing in each and every location, for that we need your help.

• reply

locations and distances

Peter van Eijk – Thu, 2010/09/09 – 08:04.

I did some research that may be relevant to this discussion, measuring distances to cloud providers. We could apply the same approach to this, but i need a little time to figure this out.

Have a look at the ‘cloud encounters’ on slideshare.

http://www.slideshare.net/pveijk/cloud-encounters-sept-2009-for-cmg-dec-6

 

any ideas?

• reply

Write up on ReadWriteWeb

Alon Swartz – Mon, 2010/09/13 – 18:40.

This comment is long overdue, but better late than never. I’d like to thank ReadWriteWeb and Audrey Watters for their article entitled: A map to your nearest data center. Hopefully with enough eyeballs we’ll be able to tweak the indexes to account for latency – not just location.

Fast connections are always better. Reminders me of a T-Shirt I saw a couple of years back saying “I’ll work for bandwidth”.

• reply

Post new comment

On the Relationship Between Python and Lisp

Lisp was way ahead of its time. Because Lisp was the first high-level programming language there is a tendency to believe that therefore everything good done since then is a reinvention of Lisp. Java is Lisp. XML is Lisp (no it isn’t). And now we have Python is Lisp.

Here is the story as presented by Paul Graham (a famous Lisp expert). Of the three languages he chooses to discuss, Java, Perl and Python, Python is considered cooler (if not more popular) than Perl and Perl cooler (if not more popular) than Java because Python is most like Lisp of the three. Unfortunately, Python is a sort of immature Lisp which may over time grow into its full Lisp-yness but why wait around when you could just be using Common Lisp today?

I’m sure if you are a Lisp programmer, it is a compelling story. Unfortunately it does not ring true.

Graham says that Perl is cooler than Java and Python than Perl. In some circles, maybe. Graham uses the example of Slashdot, written in Perl. But what about Advogato, written in C? What about all of the cool P2P stuff being written in all three of the languages? Considering that Perl is older than Java, and was at one time the Next Big Language, I think you would have a hard time getting statistical evidence that programmers consider Perl “cooler” than Java, except perhaps by virtue of the fact that Java has spent a few years as the “industry standard” (and is thus uncool for the same reason that the Spice Girls are uncool) and Perl is still “underground” (and thus cool, for the same reason that ambient is cool). Python is even more “underground” than Perl (and thus cooler?). Maybe all Graham has demonstrated is that proximity to Lisp drives a language underground. Except that he’s got the proximity to Lisp argument backwards too.

Graham himself demonstrates (in his example) that Perl’s closure semantics borrow much more heavily from Lisp than does Python. So where is the evidence that Python is closer to Lisp than Perl? In fact Perl has much more consciously borrowed features from Lisp than has Python. Perl’s Lisp-like facilities are also loved by the Perl community whereas Python’s community has had a love-hate relationship with theirs. More on this in second.

Python is not growing towards Lisp. Python’s most directly Lisp-inspired features were added very early in Python’s lifetime. Guido was a new language designer then and had not mastered the habit of saying “NO”. When people told him that he could borrow these cool features from another language he did so without entirely thinking through the consequences. For the first several years the features were an extremely bad fit. Other improvements to Python made them a slightly better fit more recently, but at the same time, other new features in Python have made them less important and less useful.

In fact, there are proposals (not yet high priority ones) to deprecate some or all of “apply” (which has a first-class syntax now), “map” and “filter” (which can always be replaced with list comprehensions), “reduce” (which can be replaced with for-loops) and “lambda” which can be replaced by named functions. These will not be removed tomorrow (don’t send me hate mail). Nevertheless, the fact that they are even being discussed for removal indicates that there is no interest in making Python more Lisp-like – rather it would be preferable to make it less so. (at the very least, the borrowing of the name “lambda” was, IMO, a horrible mistake!)

Python is growing, but not towards Lisp. As Python becomes more popular, I expect advocates of other languages will try to claim it as a descendant of theirs (call it “Alexander Graham Bell is Canadian” syndrome). Python is really a little Lisp, says Graham. A Haskell programmer could claim that Python is really a little Haskell, thanks to its support for List Comprehensions and some lazy features. An Icon programmer could claim that Python is getting to be more like Icon with the addition of lazy generators. A Smalltalk programmer would recognize metaclasses, the unit testing features and probably the new method resolution order. The warning, logging and exception handling infrastructures are probably closest to Java. In ten years, Python will probably have stolen more ideas from these languages (including Common Lisp) and they may even have stolen some back. But if you expect Python to grow towards any particular one of these, you’ll be waiting a long, long time.

In the last several versions of Python, Lisp has the least direct claim of all. The only newish feature that I can imagine as being Lisp inspired is nested scopes. But C, C++, Java, Perl and Ruby all have nested scopes. This is only a “Lisp feature” in the sense that McCarthy’s Lisp (not Common Lisp!) was the first high level programming language and all languages since have necessarily borrowed from or reinvented something pioneered there.

Look at Graham’s list of “what made Lisp different.” He shows that Python has picked up roughly five of them. C had the first three (conditionals, function pointers, recursion) thirty years ago. The next two (dynamic type checking and garbage collection) were also available in languages back then, but were considered too CPU-wasting to be mainstream until recently. The next three are the ones Python does not implement. What is interesting about them is that they have no real hardware cost. They are merely features that the programming language world in general, and Guido in particular, have chosen to reject.

Programmers do not like deeply nested expressions. They like a language that encourages a style where expression results are assigned names. A statement/expression distinction encourages (and in some cases requires) that. A symbol type is not a bad idea but the marginal gain over interned strings is minimal. And the Lisp S-expression notation has been loudly and explicitly rejected over the last half century.

In short, Graham predicts that because modern languages “grew into” some Lisp features that were at one point too computationally expensive to be mainstream, they will one day “grow into” the very features that prevented Lisp from catching on, even once the hardware and compiler techniques had caught up.

I’ll reserve judgement on the last feature on his list. Python implements two out of the three modes of evaluation he describes: evaluation at runtime and reading at runtime. The last is evaluation at compile time (macros). Python could one day grow a macro feature, perhaps based upon Dylan’s. There are still things Python can learn from languages in the Lisp family (and Smalltalk, and Haskell, and Icon, and E, and Oz, and …). The secret is to take what’s successful and leave the rest. If you have chosen not to be a Lisp programmer, then you know what I mean.

The “Accumulator” Micro-benchmark

Graham demonstrates the “power” of Lisp compared to Python by comparing tiny code snippets. Just as it is unsatisfactory to program FORTRAN in C, he demonstrates that it is unsatifactory to program Lisp in Python. No surprise there!

Rather than presenting a real-world problem, “create a ‘thing’ that can accumulate a value and return the value on request”, Graham demands the ‘thing’ be a function. Obviously this will work best in a language where functions are the central abstraction mechanism. But Python has both functions and objects as primitives. In Python, the appropriate abstraction mechanism is an object, not a function. An object is a better for choice for a variety of reasons:

• An object could have separate methods for incrementing and returning a value. In other words, the object solution is more extensible.
• An object could have other methods, such as methods that decrease or reset the value. In other words, the object solution is more extensible.
• An object would not violate the style of programming (whether functional or OO) that functions should not mutate objects other than their input arguments. In fact, “pure” functional languages enforce this convention by forcing you to express mutation as data transformation. Python is more liberal, but that does not mean that mutating closure variables is a good idea. These side-effects can lead to difficult-to-maintain code. In other words, making the ‘thing’ an object would make explicit where the state is kept and what the scope of the mutation is.

Using conventions like those described above helps Python programmers to reason about each other’s code. “No input arguments? That function is probably stateless.” “Function returns a value? It is probably side-effect free.” By the way, it is this kind of reasoning that shows why it is good for languages to have BOTH objects and functions as first-clsss types

As soon as Graham stated the problem in terms of: “create a function that has internal, updatable state” he had stepped out of the object oriented model of Python (and out of the model of pure functional programming as well). Although Python does have a variety of ways to create functions with mutable state, no Python programmer would (or should!) think of the problem in those terms.

It is therefore not surprising that Python has poor syntactic support for that formulation. Here is the idiomatic Python equivalent:

class Accumulator:
    def __init__(self, start):
        self.val = start

    def incr(self, amount):
        self.val += amount

    def decr(self, amount):
        self.val -= amount

    # not strictly necessary but makes some programmers warm and fuzzy
    def getValue(self):
        return self.val

val = Accumulator(5)
val.incr(10)
val.incr(11)
val.decr(5)
print val.getValue()

If I had restricted myself the functionality of the Common Lisp version it would have been roughly five statements/lines of code (compared to roughly five logical statements for CL).

Some Lisp geeks may never like Python. But you might.

Yesterday my wife (a new photographer) said “it seems like many (most?) of the professional photographers I know use Macintoshes.” I couldn’t resist the opportunity to engage in a little battle of the university degrees. “Yeah, Macintoshes have always been popular with the artsy crowd. Lots of pretty buttons to click.” Later that day, speaking more seriously, I told her: “if you think a Macintosh would help you in your photography, we could get one. I would like to have a look at the Unix framework embedded in it anyhow. Macintoshes are getting really popular with geeks.” She responsed: “I thought you said Macintoshes were only for artsies?”

When I made the first statement I was in a 1990s thought pattern. In the 1990s it was common to think that an operating system could be easy to use OR sophisticated but not both. But at the end of the century this dichotomy became less and less meaningful. Linux grew shiny buttons. Windows got ports of Perl, GCC, bash and the other Unix tools. And then Macintosh OSX came out and did the most impressive job of being both a family sedan and a race car at the same time. Python is the Mac OSX of programming languages. It is designed to be used and loved by new programmers, “average” programmers and language geeks all at the same time.

In his various writings, Paul Graham has strongly suggested he doesn’t think this is possible. He uses the automobile analogy and says that his new language, Arc, is designed without apology to be a Porsche. It will be harder to use at first but more “powerful” in the long run. The underlying assumption is that it isn’t possible to make a language that is both easy to use at first and more powerful in the long run. After all, if a thing goes without being done for long enough, there grows a sense of its impossibility.

A family sedan/race car is impossible because of the laws of physics. But very little is impossible when it comes to software design. Here is how you design a language or operating system or word processor that appeals to all three classes of users:

• Resolve to succeed. If you start with the philosophy that designing for the low, middle and high-end is impossible, you will have lost before you begin.
• Wait until the state of the art for all three classes is relatively established. Python builds on thirty years of experience in dynamic object oriented programming languages (Smalltalk, Lisp), thirty years of experience with easy-to-use languages (Smalltalk, BASIC, ABC) and thirty years of experience with advanced hacker’s languages (C and Lisp). Of course there are always new, exciting languages but it seems most recent academic effort has gone into statically typed languages and my observation is that statically typed languages tend to turn off a large segment of both high-end programmers (“it feels like a straight-jacket”) and low-end programmers (“I can’t even get my code to compile!”). If more recent academic programming languages have good ideas then we will have to have faith that those ideas will be brought to the masses by some other programming language thirty years from now.
• Make the tool feel like an easy tool but provide the hooks to go deep for those who want something more complicated. On Mac OSX you can hit the “terminal” button and be in Unix. In Python, you can do reflection, metaclasses, operator overloading and various different styles of programming.
• Talk to users. Guido sometimes polls educators and asks them to poll their students in turn. He also polls intermediate developers and of course gets lots of input from high-end developers.
• Sweat the details. Maybe the right function name (in a programming language) or icon (in a desktop) will make it easy to find a feature that would otherwise be hidden. For instance you could call a function “first” instead of “car” and “rest” instead of “cdr”.
• Related to the former point: admit that experienced programmers will have to relearn some things. “car” and “cdr” are in today’s Lisps because they were always in Lisp and nobody has decided to break logical compatibility with the past. Many of Guido’s admitted mistakes in Python come from borrowing too directly from C. When Guido allowed himself to innovate he came up with much more usable solutions (compare Java’s for-each syntaxes to Python’s!).
• Finally, admit that you cannot always make all categories equally happy. Sometimes you are presented with a high-end option and a low-end option and you can find a third way that pleases both groups. Sometimes there is no third way and you have to pick.

This last point might make you say: “aha, so you can’t be all things to all people, just as I suspected.” That’s true. You cannot. When I boot my new Macintosh, I will probably be offended by the CPU time wasted to make the icons pulsate. But the point is that the advantage of being able to use the same computer as my wife outweighs the minor irritants that come with using a computer that was designed for both of us.

Similarly, consider the advantages to using Python rather than a larger and more complicated language.

Tim Berners-Lee spends all day thinking grand architectural thoughts about the Web and negotiating its dangerous political waters. When he wants to hack he wants to use a language that can fit in a single “page” of his brain so he can swap it entirely in and then out again. Python is that language. Thanks to the fact that I also use Python, I can reuse his code when I want to do semantic web processing (just as I can reuse my wife’s IMac to test some Unix code I’m writing). Paul Graham says that a language designed for “the masses” is actually being designed for “dufuses“. My observation is that some of the smartest people on the planet are dufuses when it comes to programming, (or in some cases just dynamic programming languages) and I am pleased to share a language (and code!) with them.

I usually spend a big chunk of my day in Python. But most professional programmers will not be able to do that until Python is a dominant language. In the meantime they must switch back and forth between Python and the language of their day-job. Python is designed to make that easy. During the day they can pound out accounting code and at night switch to hacking distributed object oriented file systems. Every intuititively named function name makes it that much easier to “swap” Python back into your brain. After we have been away from a language for a while, we are all dufuses, and every choice made in favor of the duffers actually benefits even high-end programmers.

I get paid to share my code with “dufuses” known as domain experts. Using Python, I typically do not have to wrap my code up as a COM object for their use in VB. I do not have to code in a crappy language designed only for non-experts. They do not have to learn a hard language designed only for experts. We can talk the same language. They can read and sometimes maintain my code if they need to.

From a purely altruistic point of view, it feels good to me to know that I am writing code (especially open source code) that can become a lesson for a high school student or other programming beginner. I like to give programming classes to the marketing departments at the companies where I work.

Even hard-codre geeks get a certain aesthetic pleasure out of using something that feels minimal and simple because most of the complexity has been hidden away or removed.

If there were a high price for compatibility with low-end programmers, then maybe these benefits would not be enough to win me over. But Python is demonstrably popular among people with deep experience in other languages, including Lisps. Examples include Eric Raymond, Peter Norvig, Dan Connolly and Erann Gat. I know Scheme and Python, but not Common Lisp. Paul Graham knows Common Lisp and Scheme but not Python. Don’t trust us. The people I’ve listed above know at least one Lisp (typically Common Lisp) and Python. They have no axe to grind. They don’t seem to think they have lost something major by switching to Python.

Although Python is still not one of the most popular languages, it seems as if it is gaining popularity quickly, although it has no marketing machine behind it, no large corporate sponsor and is not embedded in a killer app ¹(as Java and JavaScript were embedded in Netscape). Ruby is another language experiencing strong growth based on customer satisfaction. Perl may rejoin this list when Perl 6 is released.

More and more programmers of all levels of sophistication seem to think that “Python gets its compromises just right”. If you aren’t willing to wait around for Lisp to take over the world (again) then I’d suggest you investigate Python or one of the other so-called “scripting languages”. I admit that Python will grow and change as you are using it. I also admit that it grows relatively organically, so nobody (including Paul Graham) can predict what, exactly, it will grow into.

1. Zope may be an app and it may be killer, but it is not a killer app for Python in the sense that there was never a time where the majority of Python programmers were using Zope, in the way that the majority of PHP users use Apache, or the majority of JavaScript (and early Java) programmers use(d) a Web browser.

Comments

True, but …

Clint Laskowski – Tue, 2011/01/11 – 15:05.

1. I wouldn’t agree that Lisp programs are always more verbose than Lisp programs. For more complex programs, I’d argue Lisp can often be more terse and usually more elegant.

2. Isn’t there a good arguement that Python is actually a member of the Lisp family? I thought I read that somewhere.

Great post on a dilema many of us are trying to resolve.

• reply

On readability and the relationship between Python and Lisp

Practical guidelines for beautiful Python code | TurnKey Linux Blog:

class IntField(int):
    def __new__(cls, val, name):
        return int.__new__(cls, val)

    def __init__(self, val, name):
        self.name = name
        self.val = val

        int.__init__(self, val)

Comments

I hope

Adrian Moya – Mon, 2011/01/10 – 13:57.

this doesn’t mean you took a look at my tkldevenv-webapp code LOL. Anyway, when you do: remember is my first time with the python/django tools. I’ll be expecting your feedback on that one. 

• reply

Oh no, I wasn’t referring to your code…

Alon Swartz – Mon, 2011/01/10 – 14:14.

I haven’t had the chance to take a look at tkldevenv yet. I’m closing up loose ends so we can finalize the 11.0 release. Once I do that I can come up for air.

I also owe you feedback on the tklpatches, haven’t forgot about that.

• reply

OOP

Guest – Mon, 2011/01/10 – 15:58.

You seem to think Python’s an object-oriented programming language.

• reply

Yes I do

Alon Swartz – Mon, 2011/01/10 – 17:27.

Is it not?

• reply

Abstractions > objects with data structures > persistance

Guest – Mon, 2011/01/10 – 22:10.

Alon, nice article… your remark: “The big advantage in building on top of Python’s conventions is that you get to re-use Python’s abstractions instead of reinventing your own,” struck me as interesting because the same could be said of Python objects, especially those with implicit data structures.

Once they are created in memory, sometimes persistence is required, i.e. preservation for later re-use. Check out the beautiful code in the y_serial module http://yserial.sourceforge.net which builds upon only standard modules for just that purpose. Good illustrations of the methods you mentioned. The code is well-communicated, perhaps overly verbose, but very instructive. You get a generally applicable NoSQL solution to boot!

• reply

speaking of python

brian mullan – Mon, 2011/01/10 – 22:58.

I recently found Jono Bacon’s Acire project/tool for Python code “snippets” contributions.

The tool itself is pretty useful as a repository of python modules you accumulate.

• reply

Python is not Java or Ruby (thank God!)

repl

¿Qué son el cloud computing y google app engine?:

¿QUÉ SON EL CLOUD COMPUTING Y GOOGLE APP ENGINE?

1 Introducción

Sin duda alguna, y lo que es peor, sin avisar, un nuevo término ha llegado para pasar a formar parte de nuestro ya de por sí extenso vocabulario tecnológico. Un concepto nuevo, o quizá no tanto, que se ha colado en multitud de sitios y que se ha propagado por la red, por los portales de tecnología, por la prensa escrita e, incluso, por la lista de tutoriales de adictosaltrabajo. Me refiero al cloud computing.

Pero, ¿qué es el cloud computing?, ¿a qué nos referimos con eso de “la nube”?, ¿por qué tantas voces predicen que es “el futuro”?, ¿es simplemente una técnica comercial o realmente hay algo “detrás”?. El presente tutorial trata de responder a todas estas preguntas centrándose en una nube muy de moda, el Google App Engine

Pero antes de explicar qué es el Google App Engine y para qué sirve es necesario dar un repaso teórico al concepto de cloud computing, la computación en la nube o “la nube” a secas y, de este modo, saber qué es, de dónde viene y dónde va.

2 ¿Qué es el cloud computing?

Hay tantas definiciones de la nube como autores han tratado de definirla, y es que parte del problema de comprender qué es el cloud computing es, precisamente, que no posee una definición concreta. En este tutorial no nos inventaremos una enésima definición del concepto y utilizaremos la de la wikipedia como referencia:

“La computación en nube, del inglés cloud computing, es un paradigma que permite ofrecer servicios de computación a través de Internet. La nube es una metáfora de Internet.”

Esta definición, como podréis ver, es tan amplia que prácticamente cabe cualquier cosa. Si yo en el trabajo conecto a través de Internet con el ordenador de mi casa para ver cómo van mis descargas, ¿estaría siguiendo el paradigma de la computación en la nube?, me temo que no

¿Pero porqué no, si estoy accediendo a un servicio a través de internet? La nube se apoya en tecnologías que llevan varias décadas funcionando que seguramente no tengas en tu casa y que no son para nada nuevas. De hecho el cloud computing es, en realidad, una remodelación del concepto de grid computing.

2.1 Grid computing

Citando de nuevo a la wikipedia:

“La computación grid es una tecnología innovadora que permite utilizar de forma coordinada todo tipo de recursos (entre ellos cómputo, almacenamiento y aplicaciones específicas) que no están sujetos a un control centralizado. En este sentido es una nueva forma de computación distribuida, en la cual los recursos pueden ser heterogéneos (diferentes arquitecturas, supercomputadores, clusters…) y se encuentran conectados mediante redes de área extensa (por ejemplo Internet)”

Nosotros, ingenuos usuarios, hacemos peticiones pensando que lo que habrá “al otro lado” será un ordenador que se dedicará a atendernos a nosotros, cuando en realidad nuestra petición es dividida en varias tareas que serán atendidas por varias máquinas dentro de una red donde puede haber cientos o miles de ordenadores.

Las diferencias entre este enfoque y el clásico modelo cliente-servidor son varias. En un modelo cliente-servidor clásico hay uno o varios clientes que conectan con un único servidor de gran capacidad. Gracias a la computación en grid lo que ponemos en el lado del servidor no es un único ordenador con mucha capacidad sino una red de ordenadores con varios cientos o miles de máquinas de menor capacidad. Esta infraestructura tiene una serie de ventajas entre las cuales destacamos:

• Posibilita el funcionamiento de aplicaciones a gran escala. De hecho para aumentar la capacidad tan sólo deberíamos añadir nuevos ordenadores a la red.

• Facilita el acceso a recursos distribuidos desde nuestros ordenadores.

• Consiguen una mayor disponibilidad, ya que en caso de fallar una máquina del grid el resto de ellas siguen funcionando y dando servicio.

Pero no todas las máquinas de la red se dedican a los mismos usos. Hay máquinas especializadas en la realización de cálculos, máquinas que contienen los datos de las bases de datos, máquinas donde se albergan ficheros, etc.

Pero, ¿qué tiene que ver todo esto con el cloud computing? Muy sencillo, que todas todas todas las aplicaciones que se encuentran en “la nube” están funcionando sobre una arquitectura basada en grid.

Entonces, ¿qué diferencia hay entre cloud computing y grid computing?. Una vez hemos visto qué es el grid, vamos a ver las distintas capas de la nube para encontrar nosotros mismos las semejanzas y las diferencias entre ambos tipos.

2.2 Capas del Cloud Computing

Aunque otros autores suelen utilizar un número de capas menor, nosotros vamos a utilizar el modelo de cinco capas. Las vamos a colocar en forma de pirámide para recalcar el hecho de que las capas inferiores poseen mayor número de elementos que las superiores.

Como ya comenté en la introducción de este tutorial nos vamos centrar en el Google App Engine así que explicaremos cada una de las capas utilizando esta nube como ejemplo. Sin embargo tenemos que tener en mente que hay otros tipos de nubes cuyas capas pueden tener usos o funcionalidades diferentes.

Dicho esto, comencemos a explicar las capas.

2.2.1 Hardware

A la vista de la pirámide podréis ver que está en la parte inferior y que es la más grande de todas. Como su nombre indica en esta capa se encuentran todos los dispositivos físicos que hacen funcionar a la nube: pasillos y pasillos con miles y miles de ordenadores unos apilados encima de otros:

En el caso que nos ocupa todo este hardware se encuentra en los datacenters de Google. Os recomiendo ver este vídeo para que os hagáis una idea de lo que es uno sólo de los muchos datacenters que Google tiene alrededor del mundo:

http://www.youtube.com/watch?v=zRwPSFpLX8I

Esta es la parte física del grid. Algunos de los ordenadores estarán destinados a almacenar datos, otros a procesar información, otros a almacenar archivos, etc. Todas nuestras búsquedas, nuestros correos de gmail, nuestros calendarios y últimamente hasta nuestros documentos se encuentran en esos ordenadores.

Todos ellos son fácilmente reemplazables y si queremos ampliar la capacidad tan sólo deberemos añadir más ordenadores o construir otro nuevo datacenter.

2.2.2 Virtualización

Como en todos los ordenadores y en todo tipo de dispositivos en general nos encontramos con que justo encima de la capa hardware se encuentra la del sistema operativo.

Otras nubes lo que hacen es instalar un sistema operativo muy reducido sobre el hardware y sobre ese sistema operativo reducido instalar máquinas virtuales con VMWare, VirtualBox, etc. Todo esto, como es natural, conlleva una pérdida de rendimiento.

Google no hace eso. Google utiliza sistemas operativos linux modificados con un sistema de ficheros propio: GFS (Google File System).

http://labs.google.com/papers/gfs.html

Con ello no sólo no pierde rendimiento sino que además va más allá de lo que un sistema de ficheros tradicional permite llegar, y es que el sistema de ficheros de Google:

1. Es un sistema de ficheros distribuido en el que participan cientos o miles de ordenadores.

2. Se diseñó pensando que los fallos en el hardware no son la excepción sino la norma.

3. Generalmente maneja ficheros con tamaños de varios gigas que pueden llegar a los terabytes.

4. Al escribir datos en disco lo normal no es modificar los que ya existen sino crear datos nuevos.

5. Los ficheros, una vez escritos, sólo se leen y por lo general de manera secuencial.

Como veis en ningún momento se menciona para nada la palabra “borrar” . Es un sistema de ficheros en el que sólo guardas, guardas y guardas, y además ficheros de tamaños enormes que se encuentran distribuidos en varios ordenadores, que luego se leen prácticamente de un tirón con lo que ahorras al disco el trabajo y el tiempo de tener que buscar sectores en concreto.

De este modo GFS consigue un objetivo claro: una capacidad de almacenamiento ilimitada.

2.2.3 IAAS (Infraestructure as a service)

Bueno, de momento tenemos una red enorme de ordenadores organizados en datacenters que tienen un sistema operativo reducido y un sistema de ficheros hecho a medida. El siguiente paso es especializar a los ordenadores que se encuentren en esa red, de tal modo que algunos de ellos se encarguen de almacenar ficheros, otros de guardar bases de datos, etc, y de esta manera continuar construyendo nuestra nube basada en una estructura grid.

Si Google quiere destinar un conjunto de ordenadores al almacenamiento de ficheros lo tiene fácil, tiene máquinas y un sistema de ficheros propio muy adaptado a sus necesidades.

Pero, ¿y si quiere dedicar máquinas a almacenar datos como si de una base de datos se tratara? Si por algo es famoso Google es por sus búsquedas, así que “algo” tendrá donde poder almacenar información, ¿verdad?

Al igual que tiene su propio sistema de ficheros, también tiene su propio sistema de almacenamiento de información. Este sistema NO ES UNA BASE DE DATOS y se le conoce con el nombre de Bigtable

http://labs.google.com/papers/bigtable.html

Bigtable es un sistema de almacenamiento de datos distribuido diseñado para almacenar cantidades de datos del tamaño de ¡petabytes! en miles de ordenadores. No sigue un modelo relacional, aunque los datos se encuentran estructurados, y todas las relaciones entre elementos se encuentran desnormalizadas.

En Bigtable, como en GFS, no se borra nada, y además las actualizaciones suponen crear nuevos registros, nunca actualizar los ya existentes. Pensad que los datos están desnormalizados: cada vez que se actualiza algo se pueden estar escribiendo muchísimos datos nuevos.

De este modo la estructura de Bigtable consigue un objetivo claro: un tiempo de respuesta mínimo.

2.3 PAAS (Plataform as a Service)

Una vez hemos llegado hasta aquí, ¿qué hacemos con los recursos de los que disponemos?, ¿cómo podemos utilizarlos?, ¿qué podemos hacer para explotarlos?

En este nivel aparece una capa que te da acceso a la plataforma que hay por debajo pero ocultándote los detalles. De este modo desarrollaremos aplicaciones utilizando una capa que usará unos recursos hardware a los que nosotros nunca podremos acceder. El almacenamiento infinito, los recursos ilimitados, la alta disponibilidad, etc ya están garantizadas gracias al grid, lo que nos encontraremos ahora serán facilidades y recursos que nos permitirán utilizarlas.

En este sentido PAAS (plataforma como servicio) actúa como una especie de API. Tus aplicaciones estarán programadas para funcionar bajo un determinado marco que te permitirá hacer cosas con esa increíble infraestructura que hay por debajo, pero no podrás hacer cualquier cosa, tan sólo podrás hacer las cosas que te estén permitidas hacer.

Y es aquí donde entra en juego el Google App Engine:

Si usas Google App Engine:

• Tus aplicaciones se ejecutarán en los ordenadores de los datacenters de Google.

• Tus ficheros se almacenarán usando GFS.

• Tus datos se guardarán en bigtable.

Y además sin tener que preocuparte de nada, tan sólo de programar una aplicación que siga las reglas que exige Google App Engine.

Esto que acabamos de comentar sirve únicamente para poder ubicar a Google App Engine en su sitio y para saber qué es realmente. Más adelante hablaremos de nuevo de Google App Engine y generaremos más tutoriales a los que podréis acceder, como de costumbre, en adictosaltrabajo.com

2.4 SAAS (Software as a service)

Y con esta capa llegamos a la parte superior de la pirámide. Tenemos una infraestructura y una serie de facilidades a nuestro alcance con un único objetivo: el de poder crear aplicaciones que puedan ser utilizadas por nuestros usuarios finales o nuestros clientes. Y es que si no tenemos ni usuarios ni clientes que utilicen las aplicaciones no hay razón por la cual crear la nube.

Para entender mejor qué es el SAAS (software como servicio) vamos a intentar describir la situación actual de las aplicaciones que se utilizan en muchas empresas.

Cuando una empresa contrata un desarrollo a medida éste suele permanecer en un servidor que se encuentra físicamente dentro del propio edificio de la organización. Se contrata el desarrollo, éste se va haciendo, y cada cierto tiempo algunas personas van a las instalaciones del cliente a instalar una nueva versión del software en su servidor.

Para ello el cliente tiene en sus instalaciones un servidor dedicado a albergar la aplicación y, ocasionalmente, un segundo servidor en el que poder mantener la base de datos con la información. También necesita tener a alguien responsable de gestionar sus sistemas, aunque su modelo de negocio no tenga nada que ver con la informática.

Este responsable de sistemas tendrá que encargarse de realizar las copias de seguridad, de que los equipos funcionen correctamente, de tener repuestos por si alguno de los sistemas fallase, etc.

Suele ocurrir, además, que este tipo de aplicaciones son utilizadas por empleados que posiblemente no se encuentren en el mismo edificio en el que esté el servidor de la aplicación, con lo que hay que mantener una conexión a Internet que funcione constantemente, hay que disponer de un ancho de banda adecuado, hay que tener una serie de medidas de seguridad, etc.

Y si la aplicación se hace más grande, la base de datos crece mucho, o se empiezan a almacenar muchos ficheros de gran tamaño posiblemente el servidor en el que está funcionando la aplicación tenga que ser sustituido por otro.

El otro enfoque es el de SAAS, que aprovecha las ventajas de la nube para eliminar todos estos problemas. Dicho enfoque apuesta por hacer que tú como cliente no tengas que tener sistemas dedicados a tener funcionando tu aplicación, sido que te facilitan los medios necesarios en los que poder hacer funcionar tu software.

De este modo el propio equipo encargado de crear la aplicación puede ir actualizando el software sin tener que desplazarse al edificio del cliente, y es el personal de la nube quien se encarga de realizar las copias de seguridad, de poner los medios para que no te quedes sin espacio en disco, de poner las máquinas necesarias para que no tengas que cambiar de servidor, etc. Aparte no te tienes que preocupar de tener una conexión a internet que funcione constantemente con un ancho de banda grande.

El SAAS para los clientes supone despreocuparse de las infraestructuras necesarias para hacer que la aplicación funcione y de los problemas técnicos que éstas puedan acarrear y, para la empresa desarrolladora de software, supone disponer de un entorno conocido y accesible con el que es más fácil poder publicar nuevas versiones del software y detectar posibles errores.

3 Google App Engine

Como hemos visto, Google App Engine es una plataforma que nos permite acceder a los recursos de Google con el objetivo de crear aplicaciones que funcionen en la nube. Se sitúa por tanto en la capa PAAS de la pirámide.

http://code.google.com/intl/es-ES/appengine/

Dichas aplicaciones, por naturaleza, funcionarán siguiendo el paradigma del SAAS (Software como servicio) y dispondrán de una disponibilidad asegurada en unos recursos prácticamente infinitos.

http://code.google.com/intl/es/appengine/docs/whatisgoogleappengine.html

El tener nuestra aplicación en la nube, como clientes, nos supondrá despreocuparnos por la infraestructura que hace que funcione nuestra aplicación pero, también como clientes, hará que nos planteemos algunas dudas, como por ejemplo ¿qué costo tiene todo esto?, ¿puedo usarlo gratis?, ¿qué tamaño pueden tener mis aplicaciones antes de empezar a pagar?

La última de las preguntas tiene su respuesta en este enlaces:

http://code.google.com/intl/es-ES/appengine/docs/quotas.html

Como podéis ver el máximo gratuito es muy muy alto:

• 1.300.000 solicitudes diarias o 7.400 por minuto.

• 10 GB de subida y de bajada de datos diaria o 56 MB por minuto.

• 1 GB de almacenamiento en el almacén de datos (el datastore).

• 10.000.000 llamadas al almacén de datos diarias o 57.000 por minuto.

• 7.000 llamadas al API de correo diarios o 32 llamadas por minuto.

• 2.000 destinatarios de correo electrónico diarios u 8 por minuto.

• …

Aparte, las aplicaciones desarrolladas con Java se encuentran con los siguientes límites:

http://code.google.com/intl/es-ES/appengine/docs/java/runtime.html#Quotas_and_Limits

• Solicitudes máximas de 10 MB.

• Respuestas máximas de 10 MB.

• 1000 archivos de aplicación como máximo.

• 1000 archivos estáticos como máximo.

• 10 MB como tamaño máximo de un archivo de aplicación.

• 10 MB como tamaño máximo de un archivo estático.

• La aplicación completa debe ocupar, como mucho, 150 MB.

En caso de ser necesarios más recursos estos se pueden contratar y así aumentar los límites, de hecho las tarifas tienen unos precios económicos.

http://code.google.com/intl/es-ES/appengine/docs/billing.html

Como desarrolladores dispondremos de una plataforma muy potente cuyo hardware no será accesible. En dicha plataforma existen una serie de facilidades que nos permitirán poder crear aplicaciones eliminándonos muchos problemas y facilitándonos muchos servicios pero, a su vez, limitándonos en otros aspectos.

Los lenguajes con los que podremos crear aplicaciones para el Google App Engine son Python y Java y los servicios a los que podremos acceder desde el Google App Engine son los siguientes:

• Almacén de datos (el datastore), donde podremos almacenar toda la información que nuestra aplicación necesite para funcionar.

• Despliegues, con lo que podremos poner a nuestra aplicación en funcionamiento.

• Cuentas de Google, que facilitará la autenticación de usuarios.

• Extracción de URL, que permite acceder a recursos de internet.

• Correo, ya que las aplicaciones podrán enviar correos electrónicos.

• Manipulación de imágenes, para poder rotarlas, recortarlas, ajustar su tamaño, etc.

• Memcache, que permite un acceso muy rápido a datos que no se encuentren en el almacén de datos.

• Programación de tareas, servicios que se vayan a a ejecutar a intervalos regulares.

http://code.google.com/intl/es/appengine/docs/whatisgoogleappengine.html

No nos tendremos que preocupar del mantenimiento de estos servicios, únicamente de usarlos. Aparte Google facilita un kit de desarrollo con el que facilitarnos el desarrollar para su plataforma.

http://code.google.com/intl/es/appengine/downloads.html

Sin embargo la propia plataforma define sus límites, los cuales al programar con Java son los siguientes:

http://code.google.com/intl/es-ES/appengine/docs/java/runtime.html

• Las aplicaciones se deben basar únicamente en un principio de petición-respuesta.

• El tiempo máximo para procesar peticiones es de 30 segundos. Las operaciones que superen ese máximo no terminarán.

• No se pueden utilizar ni hilos ni grupos de hilos en las aplicaciones, al igual que tampoco se pueden crear temporizadores.

• La aplicación no puede crear nuevos ficheros dentro de su propio ámbito de aplicación.

• Hay métodos de la clase java.lang.System que no hacen nada y cuya invocación es inútil.

• Se puede utilizar la reflexión en nuestras propias clases sin ninguna limitación, pudiendo mediante este mecanismo incluso cambiar los modificadores de acceso y ejecutar métodos privados. Sin embargo esto último no puede hacerse en las clases del JRE y del API. Puedes utilizar la reflexión contra esas clases pero no cambiar sus modificadores de acceso, con lo que no podrás ejecutar sus métodos privados.

Todo esto es debido a que Google utiliza su propia versión de la JVM, la cual es compatible con Java 6 pero posee algunas restricciones.

En la siguiente dirección tenéis un enlace a una pequeña aplicación creada con el Google App Engine:

http://adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=Tutorial-basico-google-application-engine

4 Conclusiones

Una vez el CEO de Sun, Jonathan Schwartz, comparó la evolución del suministro eléctrico con la evolución del suministro computacional. Hace mucho tiempo cada fábrica disponía de generadores de electricidad propios con los que poder abastecer sus necesidades industriales. Dichos generadores tenían que estar encendidos todo el día, poseían una capacidad máxima que no podían sobrepasar y ante cualquier avería la fábrica dejaba de funcionar.

Con el tiempo las centrales eléctricas llegaron a las industrias y muchas fábricas abandonaron los generadores para añadirse a la red eléctrica. Gracias a ella ya no tenían que encargarse del funcionamiento y mantenimiento de los generadores y podían demandar más energía si la necesitaban.

La computación posiblemente todavía se encuentre en esa primera fase en la cual las empresas poseen servidores con los cuales poder controlar su negocio. Esto supone tener personal dedicado a mantenerlo, estar limitados a lo que el hardware permita y tener que asegurarse de que desde fuera nuestros empleados pueden utilizar el software.

La nube vendría a ser lo que es ahora mismo la central eléctrica. Hay una parte que es muy importante para mi negocio que tengo fuera, que puedo utilizar sin preocuparme por la disponibilidad, que puedo ampliar fácilmente en caso de necesitarlo y que no necesito mantener.

En este sentido, ¿es la nube el futuro de la computación?. La tendencia actual parece indicar que sí, ya que lo más sensato es no distraer nuestro negocio por cuestiones tecnológicas y centrarnos en lo que tenemos que hacer, dejando a otros la responsabilidad de velar por nuestras aplicaciones y nuestra información. Actualmente hay medios y oferta para conseguir que esto sea así, así que, ¿por qué no intentarlo?, ¿vamos a tener generadores en nuestras fábricas toda la vida?

5 Referencias

http://www.siliconewhisperer.com/index.php/2009/11/24/understanding-the-layers-within-cloud-computing/

http://www.siliconewhisperer.com/index.php/2009/05/13/what-type-of-cloud-is-right-for-your-business/

http://google.dirson.com/post/3944-google-app-engine/

http://es.debugmodeon.com/articulo/introduccion-a-google-app-engine

http://www.error500.net/articulo/que-es-cloud-computing

http://www.error500.net/desarrollo/plataforma-como-servicio-paas-cloud-computing

http://www.error500.net/software/infraestructura-como-servicio-iaas-cloud-computing

Mi última pesadilla: Optimizar el VPS para WordPress:

• 

  #1 escrito por oscar
  hace 5 meses

  Citar

  hola
  me parece un poco escaso una memoria de 256 ya que como tu mismo has aprendido se lo carga el sistema en un suspiro
  seguramente si le metes 512 funcionara bien yo tengo una empresa de hosting y conozco muchas historias parecidas a la tuya
  en cualquier caso para cubrir tus necesidades tienes suficiente con un hosting y te quitaras dolores de cabeza
  un saludo

• 

  #2 escrito por Mikel
  hace 5 meses

  Citar

  Gracias por tu comentario Oscar. De momento el VPS aguanta sin caerse, parece que se ha establizado a unos 200 MB en total, pero obviamente en el futuro tendré que aumentar la RAM.

• 

  #3 escrito por NeDark
  hace 4 meses

  Citar

  Hola,

  Para optimizar PHP prueba APC (Alternative PHP Cache), aunque no es tan conocido como eAccelerator o XCache, este está más desarrollado. Es totalmente “Plug and Play” y funciona de maravilla…

  También puedes poner un servidor más ligero (Apache es pesaaaado), como nginx.

  Después la parte de optimización de WordPress creo que está perfecta.

  Como base de datos, siempre puedes probar Sqlite y así te ahorras un servicio. Creo que hay un plugin para WordPress para usar SQLite. La unica “pega” que le veo es que bloquea la tabla para la escritura, pero de todas formas es muy rápida y en los blogs casi todos son lecturas, vamos, que en una web pequeña no se nota.

  Un servidor web se puede montar hasta en 128mb si se optimiza bien.

  Suerte!

• 

  #4 escrito por Ceto
  hace 3 meses

  Citar

  Realmente me ha sido de mucha ayuda tu experiencia para mejorar el rendimiento de mi VPs, te felicito !!!

• 

  #5 escrito por Mikel
  hace 3 meses

  Citar

  Gracias Ceto. Mi trabajo me llevó xD. Suerte.

• 

  #6 escrito por Carlos Ernesto Pruna
  hace 2 semanas

  Citar

  Hola esta muy bueno el post, tengo un vps manejado, no tengo cpanel, yo lo instale desde 0, pero tengo un problema a la hora de actualizar mi wordpress o instalar algúin plugin, m pide las credenciales. No tengo idea de k tengo k hacer, he buscado muchos tutos pero m hablan de k tengo k configurar suexec y php, pero me dicen como hacerlo si tuviera un cpanel instalado……estoy buscando la variante de como hacerlo sin cpanel….bueno espero k alguien me ayude saludos y gracias de antemano

• 

  #7 escrito por Mikel
  hace 2 semanas

  Citar

  Hola Carlos, feliz 2011. Para actualizar WordPress o actualizar los plugins tienes dos opciones:

  - Desde WordPress: te pedirá el nombre de usuario y la contraseña de FTP para descargar la actualización. Tendrás que darle permisos de escritura a la carpeta wp-content de tu wordpress, y obviamente tener habilitado el protocolo FTP.

  - A través de FTP con algún programita como Filezilla que te permita conectarte por FTP a tu servidor.

  Hay una tercerá opción, que es hacerlo a través de SSH con el comando wget. Este comando te permitirá descargarte el archivo de actualización de wordpress o el plugin que quieres actualizar o instalar.

  Espero que esto te haya ayudado un poquito.

  Un slaudo

Cloud Hosting | Powered by LayerEdge | vexxhost.com:

Virtual Private Servers

The next generation of virtual private servers, renamed to cloud servers, offer the same affordability and ease of management for you, with added granular scalability and full redundancy.

Youtube Downloader « PHP recipes « ActiveState Code:

PHP, 44 lines

Download

Copy to clipboard

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

<?php
/*

	This is a basic functions used to show real URI of FLV files at youtube.com so we can
	download the file and play it offline. 
*/

function get_content_of_url($url){
	$ohyeah = curl_init();
	curl_setopt($ohyeah, CURLOPT_RETURNTRANSFER, 1);
	curl_setopt($ohyeah, CURLOPT_URL, $url);
	$data = curl_exec($ohyeah);
	curl_close($ohyeah);
	return $data;
}


function get_flv_link($string) {  
	if (eregi("watch_fullscreen(.*)plid", $string, $out)) {  
		$outdata = $out[1];
	}  
	$arrs = (explode('&',$outdata));
	foreach($arrs as $arr){
		list($i,$x) = explode("=",$arr);
		$$i = $x;
	}
	$link = 'http://www.youtube.com/get_video?video_id='.$video_id.'&t='.$t;
	return array($video_id,$link);
} 

function get_youtube($url){
	$stream = get_content_of_url($url);
	return get_flv_link($stream);
}


/* ######## SAMPLE OF USAGE ##########
 * <?php
 * require_once('youtube.lib.php');
 * $link = get_youtube($youtube_url); 
 * echo $link[0];
 * ?>
 * 
 */

Letters to the World » Subtitles for Netflix, à la Python:

18 Comments »

1. [...] Codeman38 has created Python version that works on Macs and I assume Linux. Posted in code, powershell | Tags: close, dfxp, Instant [...]

   Pingback by Netflix subtitles | Josh Erickson — 29-Jul-2010 @ 12:44 pm

2. [...] reading Codeman38‘s blog edit I figured I can’t leave my Windows brethren behind in the dust when it [...]

   Pingback by Srt2DFXP v0.2 and a GUI! | Josh Erickson — 29-Jul-2010 @ 11:22 pm

3. Thank you for your help. I went to Josh’s site and could follow his guide. Much grateful.

   Comment by Osvaldo — 24-Aug-2010 @ 12:44 am

4. @Osvaldo: Glad I could help! This is a feature that seriously needs to be publicized more, since Netflix and/or the studios can’t be bothered to provide their own subtitle files when the feature exists…

   Comment by codeman38 — 24-Aug-2010 @ 12:46 am

5. This is awesome. I’m on a Mac platform so I downloaded the Python script in the comments above & it looks like I’m able to convert the SRT to DFXP, but when I try to load it in the player menu, I get “Custom: Not Supported”. I got the SRT from opensubtitles.org. Just hoping to get some troubleshooting steps…

   Comment by Chris — 29-Aug-2010 @ 11:23 am

6. @Chris: There’s probably a formatting error in the subtitle, like an italics tag that’s opened or closed twice. I’ve had this issue with a few subs from SubScene.

   Comment by codeman38 — 29-Aug-2010 @ 11:25 am

7. @codeman38 You’re right. I played around with it some more and realized I could get it to work. Depends on the subtitle I downloaded. Do you prefer any particular subtitle site over another? I also thought it’d be nice to wrap this script into a GUI via Xcode or maybe even a Safari Extension if Safari Extensions support it.

   Comment by Chris — 06-Sep-2010 @ 1:18 pm

8. @Chris: No preference on subtitle sites; I’ve used SubScene, OpenSubtitles and TVSubtitles depending on the movie/show.

   I’ve actually been considering writing a GUI wrapper for it myself, when I actually have some time to do that – though you’re welcome to contribute anything; I should set up a GitHub site or something. Don’t know if a Safari extension would be so easy, at least if you’re wanting to convert subtitles directly from downloads; most of the sites I’ve seen zip their subtitle files before transferring them, and I’m not entirely sure Safari extensions can handle that.

   Comment by codeman38 — 06-Sep-2010 @ 1:22 pm

9. @codeman38 I’d definitely be interested in helping make a GUI, only problem is I’ve never done it before. This would be as good a motivation as any to learn though. Such as, at first the plan would be to get a GUI working & then maybe later add the ability to search for & download the subtitles, by searching the main subtitle sites.

   One of the major issues I’m having is getting the timing right. Seems to take me quite a few times. That’s why I wonder if any one subtitle is better than another.

   Comment by Chris — 06-Sep-2010 @ 1:41 pm

10. @Chris: Yeah, my GUI experience is mainly in Linux (GTK) and Windows (WinForms). I’ve toyed around with designing GUIs in Interface Builder a bit, but I still need to learn how to interface that with Python.

    As for timing, my experience has been that the timing is pretty much the same on all the sites. Typically the issue is that Netflix gets a different print from the studios for streaming than what’s used on the DVD.

    Comment by codeman38 — 06-Sep-2010 @ 4:33 pm

11. Would it be possible for you to post a few screenshots of what it should look like before and after you run the command? I’m not very tech-savvy and I’m having trouble figuring out what I’m supposed to type to get the program to work. I’m typing in what’s shown on this page but with a different file name and it’s just not working! Also, where is the .srt supposed to be saved to so that the program can find it?

    Comment by shelly — 23-Sep-2010 @ 10:28 am

12. @shelly: If you’re not familiar with the Terminal, the best idea is to put both the .srt and the Python script in your home directory. Then it should work pretty much as described. If that doesn’t work, try “python srt2dfxp.py” instead of “./srt2dfxp.py”.

    I really need to write a GUI version, but I’m far too busy with other stuff to really be able to concentrate on it– the shell-script version used enough of my time.

    Comment by codeman38 — 23-Sep-2010 @ 10:30 am

13. [...] which means Windows only, but a talented Python developer also found the same blog ahead of me and ported the script to python for us Mac OS or Linux users.  Also worth noting that Josh has developed a GUI for the script that [...]

    Pingback by Netflix Subtitles « Hearn’s Blog — 27-Sep-2010 @ 6:30 pm

14. I think I might be able to save some you some time on the GUI project. There’s an easy way to convert the .srt files to .dfxp. (I was trying to fix the “Custom: Not Supported” problem and stumbled across it)
    1. Download Jubler from http://www.jubler.org/
    2. Open the subtitle file you wish to convert in Jubler
    3. Save the file in a W3C Timed Text format with UTF-8 encoding
    4. Change the extension of your newly created file to .dfxp

    Comment by David — 30-Sep-2010 @ 5:14 pm

15. @David: Ooh, good catch! I’ve even used Jubler, and never noticed that its DFXPs were Netflix-compatible.

    Comment by codeman38 — 30-Sep-2010 @ 10:48 pm

16. @David — Nice catch! It doesn’t seem to be working on my Mac at the moment.. When I convert the file and rename it, Netflix doesn’t recognize the file. Could this be a mac thing?

    Comment by DaFyre — 14-Nov-2010 @ 1:22 am

17. @DaFyre: Make sure that you’re saving it with UTF-8 encoding.

    Comment by codeman38 — 14-Nov-2010 @ 1:31 am

18. [...] which means Windows only, but a talented Python developer also found the same blog ahead of me and ported the script to python for us Mac OS or Linux users.  Also worth noting that Josh has developed a GUI for the script that [...]

    Pingback by Netflix Subtitles | churnd — 18-Nov-2010 @ 7:42 pm