Dave Mello Lead Systems Engineer Hi, I'm Dave. I've been working at Newfangled since 1998. I do computer stuff. | Dave Mello's Blog |
 | Subscribe to this blog Click this link to view blog as XML. View a list of all Newfangled blogs >> Subscribe to all Newfangled blogs >> |  |
Scalability according to eBay
June 27, 2008 at 3:15 PM by DaveInteresting article about scalability from eBay, who obviously has a strong vested interest in the subject. They touch on a few different concepts, from application architecture to data organization. From the article:
Said another way, scalability is the shape of the price-performance curve, as opposed to its value at one point in that curve.Read the complete article read more... |
Tags: Scalability, architecture
 |  |  |  |  |  |  |
Google IO, Day 1
May 28, 2008 at 8:45 PM by Dave| Today was day one of Google's annual developer conference, at the Mascone Center in San Francisco. Geared towards the developers that use Google's services, and offering " In-depth technical sessions, hands-on training, and face time with engineering teams", the conference attracted more than 3000 web professionals for a session-packed, two-day event.
The day kicked off with the keynote, hosted by Vic Gundotra, giving a good overview of Google's investment in the developer community. With many guest speakers chiming in on various areas of focus, some key points were Google's impact on the HTML 5 spec, some feature and pricing announcements on Google App Engine, and the release of GWT 1.5. Overall, judging from session attendance and overall feedback, it seems that App Engine and Android are the two areas that are garnering the most interest from the developer community. Actually, one of the most tangible aspects of the concept so far is the general enthusiasm and excitement over the technologies and concepts being presented. Compared to past industry events that I have attended, there is a noticeable sense of direction that is new, which honestly is really exciting and refreshing.
|
Tags: conference awesome
| | | | | | |
Google App Engine
April 20, 2008 at 4:00 pm by Dave
From a development perspective, Google provides a fantastic SDK to get started. I was up and running a development server on my mac in a matter of minutes. It quickly became clear is that things are tailored to make it *very* easy to use other google services. App deployment is very straightforward. The database model is different than what most people might be used to. In this move into Platform-as-a-Service (Paas), the direct comparison seems to be against Amazon's well established suite of web services. As Garrett Rogers points out, however, this isn't really the case, at least not yet. Amazon offers a wide range of building blocks, mainly their EC2 cloud environment and tools such as SimpleDB and Simple storage. Amazon offers these services in a loosely bundled al-la-carte manner, where the developer ties them together. Google has taken a different approach by bundling everything together in a completely managed, but much more limited environment. It has actually been compared more closely to facebook than to amazon's web services.While Google's initial approach has its advantages and disadvantages, I think the real point here is that google is choosing to focus on just one subset of the market - the startup developer looking for a quick all-in-one solution. My guess is that this was a decision made in order to release the environment to the community as early as possible. It will be interesting to see what areas they focus on improving in the coming months. The very day App Engine was released, the team at Google listed several areas that they knew the community would feel were too limited. I'm really excited to see how the following areas grow as the environment matures, and watch the process with our specific needs in mind. "1. Support for more languages. We're obviously huge Python fans, but we recognize that there are other great languages out there that developers use to build web applications."Python is a great language. I've spent more time looking at it over the past week than I had in the past, and I already feel pretty proficient in it. This is testament to a logical and consistent nature of the language, and I think for anyone not familiar with it the learning curve will be pretty low. From a practical standpoint, however, there are downsides to this choice. For companies such as ours, the inability to re-factor legacy code where appropriate is obviously an issue. For google's core target, the startup developer, this limitation means that they do not have access to the vast amount of community resources and pre-written modules that seem (in my unscientific initial review) to be more prevalent for other scripting languages. It makes sense that Google initially opted to only support Python, since in essence they had to create a sand-boxed version of the engine to run within their environment, and they obviously have the most internal experience with that language. I'm curious how they would approach doing the same thing with say PHP, and it's more chaotic community. "2. Support for offline processing. Right now Google App Engine is great for web apps that do all of their processing in response to user requests, but what about apps that need to perform scheduled tasks or larger-scale data migration? We'd like to support those apps too." Basing all processing on user requests prevents some pretty common concepts that would be required by any advanced application. At the very least, this limitation would lead to some horrible architecture hacks to support these types of tasks. Right now the excepted solution seems to be to have a separate machine that periodically "triggers" requests to the App Engine app. Of course that raises the question of how do you scale a separate service to keep up with an automatically scalable main environment. But really the correct solution will be some sort of scheduling service within the App Engine environment itself. "3. Support for large files. Google App Engine currently imposes a limit of 1MB on all requests, both inbound and outbound. We're interested in providing efficient support for much larger uploads and downloads." This is an area that I'm pretty sure will be addressed early on, but I'm more curious as to the potential for large file storage mechanisms living within the Google cloud. The approach will be a little different from the typical LAMP paradigm, but thats not necessarily a bad thing. The white-paper on Google's BigTable database alternative has an interesting section on the way the google maps data is stored/queued. "4. Billing for additional quota. During the preview release period, all apps are restricted to a set of free resource quotas. Although Google App Engine will always be free to get started, we plan on allowing developers to purchase additional resources in the future, while paying only for what they use." This is the area, I think, that will really show us what Google's long-term intentions for this service are. So far, very little has been said on the matter, except that basically it will be remain free for the type of usage that is possible now, with the inherent resource limitations. How the next-step pricing tier gets defined will be very interesting, and may prevent some industries from fully benefiting from all the service has to offer. In our case, we may find an opportunity to rethink the way we approach hosting completely. Of course there are other critical areas are that are unknown at this point. When will the https protocol be supported? And there's the issue of lock-in, which Chris Anderson absurdly and elegantly addresses. I'm pretty excited to see these limitations addressed as things mature, and watch what is starting out as a limited beta release quickly grow into an extremely powerful and useful service that will have lasting ramifications on the way we think about web application hosting, deployment, and development in general. Plus, it has a cute logo. |
Tags:
| | | | | | |
Blurry Display in OSX
January 30, 2008 at 11:51 am by Dave| Last night, I noticed that everything on my screen was looking a lot blurrier than I remembered. OSX has always had a bit of a funky approach to font aliasing, but this was impacting everything, including images. Changing monitors had no impact. I was just about to start researching "sudden loss of vision", when I realized that Universal Access "Zooming" was enabled. Somehow, my screen was zoomed in by about 3 pixels - just enough to make my eyes really hurt, while not being terribly noticeable otherwise. Here's a comparison of before and after I disabled zooming:   Anyway, to disable zooming, go to the "Universal Access" system preference, or hit Alt-Apple-8 |
Tags: OSX mac troubleshooting
| | | | | | |
Better Code Through Commenting
January 29, 2008 at 4:15 pm by Dave Commenting one's code is a fundamental principle of good programming. The benefits are clear. Functionality is more easily understood, with less of a learning curve for new employees who have better things to do than analyze your code. In an industry with a relatively high turnover rate, this becomes even more important. I've come to realize, however, that the commenting of code can serve a more selfish, and perhaps a fundamentally more useful purpose. When I initially approach an area of a project to focus on, my goal is usually to work all the way through to the most basic endpoint as quickly as possible, and then layer additional functional requirements on top of that. This gives me a framework in which testing can easily be conducted as new functionality is added. With this approach, commenting becomes the first step to the programming process, with the major concepts defined and organized by comment blocks, to be worked out later. The advantage to this approach is that it lets the major aspects of a programatic concept be conceptualized by the developer in large brush strokes. This is particularly useful in the higher-level areas of a system, where a strictly object-based organizational scheme might not be terribly pragmatic. There are some welcome side-effects as well. The human attention span can really only process about 5-9 distinct items or concepts simultaneously at any given point. So, by breaking out the problem clearly first, and then dealing with individual areas, one is able to consider with greater accuracy the implications of the particular task at hand. In addition, the final product will be organized and commented in such as way that clearly illustrates not just what the code does, but how the developer initially approached the problem. This, I have found, is much more illuminating to future programmers as they try to dissect how the code works. |
Tags: coding lessbad
| | | | | | |
RSS