Hello.

This blog post provides a basic overview of web architecture concepts that are helpful for new web developers. It covers a standard, scalable web stack and discusses the benefits and tradeoffs of using Platform as a Service tools like Heroku, Firebase, or AppEngine for simplifying development, even with higher costs.

This blog post describes an experiment using Google Cloud Functions to handle web push notifications for services that don't natively support them. I needed a way to process incoming webhooks from various sources like Travis CI and GitHub, transform their payloads into a consistent format for web push, and ensure the system could scale and remain isolated. Google Cloud Functions provided a serverless solution, allowing me to create separate functions for each webhook source. The front-end receives the webhook, pushes the data to a designated Pub/Sub queue, and the corresponding cloud function processes the message and publishes the transformed data to another queue for sending the web push notification. This setup allows for flexibility, scalability, and isolation, fulfilling all my initial requirements.

LocalStorage is a flawed API with poor querying, performance issues, limited storage, inconsistent event handling, and locking problems. Its only advantages are its simple semantics and browser support. Continued use of LocalStorage hinders the development of robust offline and client-side web apps. We should transition to IndexedDB, a superior alternative. I've demonstrated this by converting the BackboneJS TodoMVC example from LocalStorage to IndexedDB using Julien Genestoux's adapter. This involved a few configuration changes, highlighting the ease of adopting IndexedDB, which is our only viable path forward for client-side storage. Let's abandon LocalStorage and embrace IndexedDB to unlock the potential of offline web apps.

I have mixed feelings about SVG. I find it complex and requiring specific tools, and its integration with the web is clunky. It feels like a context switch between HTML and SVG DOM. However, SVG is scalable, vector-based, and has powerful graphical capabilities like filters and paths, enabling things not possible with regular web technologies. I wish path could be a CSS property, simplifying its usage and allowing text or even block elements to be rendered along a path. This would be more efficient than embedding SVG within HTML elements.

Day 2 of DevWeek was packed with insightful sessions. Niels Berglund's talk on ADO.NET v.Next and the Entity Framework highlighted the potential for simplifying database interactions by mapping database models to programmer-friendly models. Kelvin Henney's lecture on streamlined object-oriented analysis emphasized the importance of modeling the current system before designing solutions, using UML and Use Cases. Ingo Rammer's presentations on scalability and performance, and Windows Workflow integration, offered practical advice and cleared up some misunderstandings. I also had a chance to visit vendor booths, with Infragistics' XAML components and Dev Express's slick presentations standing out. Overall, the quality of the lectures has been excellent, but the vendor presence could be improved.

This post responds to Mike Champion's comment on my previous XLinq blog post. I clarify the XML file used (Wikipedia XML Abstract) and explain why I chose an XMLReader for its speed, especially when combined with custom data structures for a cyclic graph representation. XLinq's syntax and lambda expressions felt less intuitive for my task of converting XML into SQL statements. The project involves relating "title" elements with "sublink" entities, resulting in a complex graph structure not easily handled by XLinq without excessive data duplication and memory consumption. While XStreamingElement offers some improvement by avoiding redundant data scans, I desire deferred data loading for processing only necessary slices of the XML. This approach could handle selects, wheres, and counts efficiently in a single pass, and even joins with clever indexing. Defining a schema during XML iteration seems redundant when XLinq expressions already specify data requirements. Pre-loading entire XML documents into memory feels inefficient when only a small portion is used. I propose deferring data loading until needed, despite potential issues with repeated XDocument inspections. Ideally, XLinq should scale without forcing users to revert to less efficient methods due to data size limitations. I inquire about potential hard limits and scaling formulas related to XML document size in XLinq.

This blog post explores the techniques used by high-traffic websites like Digg and Zooomr to handle large numbers of simultaneous users. It delves into performance optimization strategies to improve website efficiency and prevent crashes under heavy load. Click the link to learn more.