Another small nugget of practical knowledge from me. When you’re building a project as a solo developer, you need a quick way to gather feedback or collect data without reinventing the wheel. While you can always write more code, you often don’t have to. Sometimes, you can even ship something with just a frontend! Pre-filled Google Forms can offer a solution in these situations. Whether you need to create a basic contact form, allow order customization, gather feature requests and bug reports, or collect structured data from users, this method is simple, effective, and easy to implement. The strength of this approach lies in passing the data from your app into the form URL and auto-filling certain fields to save users time and encourage them to complete the form. Also, you may pass identifiers allowing you to integrate this data quickly without manual parsing. Real-world Example: Gathering Airport Data Let’s say you’re running a project like mine - airportregistry.com, where users can look up and manage information about airports worldwide. You want to let users quickly request corrections or updates to airport data directly from the site. Instead of asking users to manually enter details about the airport they’re viewing, you can pre-fill these fields in a Google Form with data from your site, making it much easier for them to submit feedback. Here's an example: const requestInfoLink =
  `https://docs.google.com/forms/` +
  `d/e/1FAIpQLSfAVYhpjNOZR6_gMPJPtlFYPRqGaem_rFb8nQ4CV27VTgmGzA/viewform?usp=pp_url` +
  `&entry.1513837494=${airport.airport}` +
  `&entry.20379740=${airport.iataCode}` +
  `&entry.475896124=${airport.location}` +
  `&entry.166674403=${airport.country}` +
  `&entry.60635846=${airport.continent}`; With this setup, when a user clicks the feedback link, they’ll be taken to a Google Form with details like the airport name, IATA code, location, country, and continent already filled in. This removes friction and increases the chances that users will provide meaningful feedback. How to Create a Pre-Filled Google Form Create a new form: Start by creating a new Google Form with the fields you need. For example, you might include fields like “Airport Name,” “IATA Code,” “Location,” etc.


Set up pre-fillable fields:


Click the three-dot menu (ellipsis) in the upper right corner and choose "Get pre-filled link."


Enter some placeholder values in the fields you want to pre-fill. Use easily recognizable placeholders like “AirportNamePlaceholder,” “IATACodePlaceholder,” etc. This makes it easier to identify and replace them in the generated link.


Click "Get link," and copy the URL provided by Google.




Customize the link:


The URL you copied will contain placeholders that look something like entry.123456789=AirportNamePlaceholder.


Replace these placeholder values with variables or data from your app, as shown in the example above. Tada! You saved yourself some time you would waste writing frontend and backend code. Wrapping Up Pre-filled Google Forms offer a straightforward way to integrate feedback and data entry mechanisms into your app without writing code. Use the time saved to really focus on providing value with other features in your app. Do you think this is bad? How many users does your app have? Hm? If you liked this content, please support me by sharing this post and subscribing to my Newsletter. Also, check out the website where I applied this technique - airportregistry.com! You can also find me here: x: horosin
LinkedIn If you want to follow me here – click the subscribe button on the left. Thanks for the support! Another small nugget of practical knowledge from me. When you’re building a project as a solo developer, you need a quick way to gather feedback or collect data without reinventing the wheel. While you can always write more code, you often don’t have to. Sometimes, you can even ship something with just a frontend! Pre-filled Google Forms can offer a solution in these situations. Whether you need to create a basic contact form, allow order customization, gather feature requests and bug reports, or collect structured data from users, this method is simple, effective, and easy to implement. The strength of this approach lies in passing the data from your app into the form URL and auto-filling certain fields to save users time and encourage them to complete the form. Also, you may pass identifiers allowing you to integrate this data quickly without manual parsing. Real-world Example: Gathering Airport Data Let’s say you’re running a project like mine - airportregistry.com , where users can look up and manage information about airports worldwide. You want to let users quickly request corrections or updates to airport data directly from the site. airportregistry.com airportregistry.com Instead of asking users to manually enter details about the airport they’re viewing, you can pre-fill these fields in a Google Form with data from your site, making it much easier for them to submit feedback. Here's an example: const requestInfoLink =
  `https://docs.google.com/forms/` +
  `d/e/1FAIpQLSfAVYhpjNOZR6_gMPJPtlFYPRqGaem_rFb8nQ4CV27VTgmGzA/viewform?usp=pp_url` +
  `&entry.1513837494=${airport.airport}` +
  `&entry.20379740=${airport.iataCode}` +
  `&entry.475896124=${airport.location}` +
  `&entry.166674403=${airport.country}` +
  `&entry.60635846=${airport.continent}`; const requestInfoLink =
  `https://docs.google.com/forms/` +
  `d/e/1FAIpQLSfAVYhpjNOZR6_gMPJPtlFYPRqGaem_rFb8nQ4CV27VTgmGzA/viewform?usp=pp_url` +
  `&entry.1513837494=${airport.airport}` +
  `&entry.20379740=${airport.iataCode}` +
  `&entry.475896124=${airport.location}` +
  `&entry.166674403=${airport.country}` +
  `&entry.60635846=${airport.continent}`; With this setup, when a user clicks the feedback link, they’ll be taken to a Google Form with details like the airport name, IATA code, location, country, and continent already filled in. This removes friction and increases the chances that users will provide meaningful feedback. How to Create a Pre-Filled Google Form Create a new form: Start by creating a new Google Form with the fields you need. For example, you might include fields like “Airport Name,” “IATA Code,” “Location,” etc. Set up pre-fillable fields:


Click the three-dot menu (ellipsis) in the upper right corner and choose "Get pre-filled link."


Enter some placeholder values in the fields you want to pre-fill. Use easily recognizable placeholders like “AirportNamePlaceholder,” “IATACodePlaceholder,” etc. This makes it easier to identify and replace them in the generated link.


Click "Get link," and copy the URL provided by Google. Customize the link:


The URL you copied will contain placeholders that look something like entry.123456789=AirportNamePlaceholder.


Replace these placeholder values with variables or data from your app, as shown in the example above. Create a new form: Start by creating a new Google Form with the fields you need. For example, you might include fields like “Airport Name,” “IATA Code,” “Location,” etc. Create a new form: Start by creating a new Google Form with the fields you need. For example, you might include fields like “Airport Name,” “IATA Code,” “Location,” etc. Set up pre-fillable fields: Click the three-dot menu (ellipsis) in the upper right corner and choose "Get pre-filled link."


Enter some placeholder values in the fields you want to pre-fill. Use easily recognizable placeholders like “AirportNamePlaceholder,” “IATACodePlaceholder,” etc. This makes it easier to identify and replace them in the generated link.


Click "Get link," and copy the URL provided by Google. Set up pre-fillable fields: Click the three-dot menu (ellipsis) in the upper right corner and choose "Get pre-filled link." Enter some placeholder values in the fields you want to pre-fill. Use easily recognizable placeholders like “AirportNamePlaceholder,” “IATACodePlaceholder,” etc. This makes it easier to identify and replace them in the generated link. Click "Get link," and copy the URL provided by Google. Click the three-dot menu (ellipsis) in the upper right corner and choose "Get pre-filled link." Click the three-dot menu (ellipsis) in the upper right corner and choose "Get pre-filled link." Enter some placeholder values in the fields you want to pre-fill. Use easily recognizable placeholders like “AirportNamePlaceholder,” “IATACodePlaceholder,” etc. This makes it easier to identify and replace them in the generated link. Enter some placeholder values in the fields you want to pre-fill. Use easily recognizable placeholders like “AirportNamePlaceholder,” “IATACodePlaceholder,” etc. This makes it easier to identify and replace them in the generated link. Click "Get link," and copy the URL provided by Google. Click "Get link," and copy the URL provided by Google. Customize the link: The URL you copied will contain placeholders that look something like entry.123456789=AirportNamePlaceholder.


Replace these placeholder values with variables or data from your app, as shown in the example above. Customize the link: The URL you copied will contain placeholders that look something like entry.123456789=AirportNamePlaceholder. Replace these placeholder values with variables or data from your app, as shown in the example above. The URL you copied will contain placeholders that look something like entry.123456789=AirportNamePlaceholder. The URL you copied will contain placeholders that look something like entry.123456789=AirportNamePlaceholder . entry.123456789=AirportNamePlaceholder Replace these placeholder values with variables or data from your app, as shown in the example above. Replace these placeholder values with variables or data from your app, as shown in the example above. Tada! You saved yourself some time you would waste writing frontend and backend code. Wrapping Up Pre-filled Google Forms offer a straightforward way to integrate feedback and data entry mechanisms into your app without writing code. Use the time saved to really focus on providing value with other features in your app. Do you think this is bad? How many users does your app have? Hm? If you liked this content, please support me by sharing this post and subscribing to my Newsletter . Also, check out the website where I applied this technique - airportregistry.com ! Newsletter Newsletter airportregistry.com airportregistry.com You can also find me here: x: horosin LinkedIn x: horosin horosin horosin LinkedIn LinkedIn LinkedIn If you want to follow me here – click the subscribe button on the left. Thanks for the support!

Quickly Get Feedback and Data for Your App Using Pre-Filled Google Forms: A Guide

I want to talk about a quick tweak you can do in your CDN TTL settings to radically improve your site’s performance. Direct impact on Time-To-First-Byte (TTFB) metric, but as a halo effect, pretty much every other Web Vital. You can do this in any CDN since TTL customization is a pretty standard need, and most CDN providers have easy ways to create rules for various rule configurations. I use Cloudflare for my blog’s CDN layer. Cloudflare already comes with nice defaults for optimizing the delivery of static assets like images, javascript, css files. But for HTML documents, CDNs use cache-control headers to determine how to cache, and how long to cache. Applications return this header, and it’s a way for the application (origin) to tell CDNs how to behave on certain pages. But in this optimization method, we’ll simply override all (or most) of our pages to be highly cached and served from the cache while revalidating in the background. The way this works is CDN always serves the “last” cached HTML to the reader (or crawler) from the edge network, really really really fast (in some cases double-digit milliseconds), and triggers a request to the origin server to get the “latest” version. Most applications also return proper response codes if the content hasn’t changed from the timestamp that CDN will ask if there is a new update to the content. How to Configure Custom TTL in Cloudflare To set up custom edge TTL in Cloudflare, navigate to your site page, Caching > Cache Rules page. Create a new rule, give it a name, and then set up the request path configuration. You can set multiple expressions, and exclude patterns that you know are Admin, or Rest API, or other URLs that should NOT be cached long. I use WordPress for my blog, and I exclude paths containing things like wp-admin, wp-json, cron… Then, select “Ignore cache-control header,” and use this TTL in the Edge TTL section. And finally, select how long you want to cache. Longer is better because longer means most of your site content, including long-tail content that doesn’t get consistent traffic, will also be cached at the edge. I started with 1 day, then 1 week, then I tried 1 month, but then had some pages stuck in the cache too long and dialed it back to 1 week as my sweet spot. Even if you’re not using Cloudflare, I’m sure there is an equivalent of this in your CDN provider. What Is the Impact on Page Speed? After the change, I saw a big drop (like 90% reduced load) in my server’s load. It meant CDN was doing what it was supposed to do. It’s one of the positive side effects of doing higher cache offload to CDN, to be able to scale higher traffic without needing powerful hosting resources. My Time-To-First-Byte decreased (improved) 70%, coming from shy of 500ms down to 100–160ms range 🤯 More importantly, the real user experience on the page became even more mind-blowing because things became super snappy. Click click click, bam bam bam, nothing was in a visible loading state anymore. Even if metrics didn’t move, I am super happy with this aspect of the change. 🤯🤯🤩 I got my Cloudflare Web Analytics email and noticed almost all Web Vitals moved positively at least 30% improvement. I wasn’t expecting other Web vitals like CLS and LCP to be directly impacted (or impacted as much as they did). But it makes sense. When the assets load much faster like this, the “wait time” (or blocking time) goes down, therefore, the layout shift or the largest paint goes down. SEO Impact It’s a well-known fact that Google takes your “core web vitals” into account when determining your ranking in the search results. This change has more impact on crawlers than you think. Because most of the time, crawlers’ requests are the ones that hit “cache cold” pages. It means Google (or other search engines) is reading your site holistically way more than your real users. Imagine every single article you wrote. There is no user who reads every single one of them — Google does 🙂 (and does it regularly). When a crawler tries to visit a page that nobody read in a long time, its request will have cache-miss more likely than cache-hit, so it will “wait” longer for your web server to render the page. When you put yourself in the crawler’s shoes, imagine you try to read 10,000 articles/pages on a site over a day or two period (maybe it takes longer, who knows…). Now, consider the percentage of those pages that will have to be rendered, or served from the CDN cache. The more pages Google sees “slow”, it will think your whole site is slow. This is where the real value of super-long TTLs comes in. Especially if you combine that with serve-stale-while-revalidate (SSWR) which most CDNs automatically do (if not, I’m sure there is a setting you can enable these together). SSWR, with a super-long TTL (like 7 days, or more), basically creates an infinite loop of “always cached” scenarios. And with that, your crawler traffic gets served from the cache (at cost/risk of “stale content” which is OK in the vast majority of use cases), and directly increases your site’s overall speed score and, therefore your SEO scores. Content Freshness There is one caveat though, which is content freshness. When you bump the Edge TTL up to multi-day TTLs like I did, you need to make sure your CMS/site is nicely integrated with your CDN’s cache clear systems, in the case you make updates. Two scenarios: You update existing content (like fixing a typo or changing the cover image of a post); the change should be reflected on the content’s detail page right away. You publish new content, so the new content is supposed to show up in common places like your homepage. You can use your CDN’s cache clear UI or APIs to trigger “purge” on URLs you think it’s impacted (homepage, section pages, etc.), or highly visible pages like the homepage can be configured with a lower TTL in a separate cache rule set. I use WordPress for my content management system and Cloudflare has a WordPress plugin to listen to publish/update hooks to trigger these cache clear nicely. Another way to think about this is to find the balance. What is the “staleness” you can tolerate on a page? Let’s say another article detail page showing “recent articles” or “related articles” sections to NOT show your most recent article there. As long as that time length is not something you can’t afford, cache longer to achieve better site/page performance. I want to talk about a quick tweak you can do in your CDN TTL settings to radically improve your site’s performance. Direct impact on Time-To-First-Byte (TTFB) metric, but as a halo effect, pretty much every other Web Vital. You can do this in any CDN since TTL customization is a pretty standard need, and most CDN providers have easy ways to create rules for various rule configurations. I use Cloudflare for my blog’s CDN layer. Cloudflare already comes with nice defaults for optimizing the delivery of static assets like images, javascript, css files. But for HTML documents, CDNs use cache-control headers to determine how to cache, and how long to cache. Applications return this header, and it’s a way for the application (origin) to tell CDNs how to behave on certain pages. But in this optimization method, we’ll simply override all (or most) of our pages to be highly cached and served from the cache while revalidating in the background. The way this works is CDN always serves the “last” cached HTML to the reader (or crawler) from the edge network, really really really fast (in some cases double-digit milliseconds), and triggers a request to the origin server to get the “latest” version. Most applications also return proper response codes if the content hasn’t changed from the timestamp that CDN will ask if there is a new update to the content. How to Configure Custom TTL in Cloudflare To set up custom edge TTL in Cloudflare, navigate to your site page, Caching > Cache Rules page. Create a new rule, give it a name, and then set up the request path configuration. You can set multiple expressions, and exclude patterns that you know are Admin, or Rest API, or other URLs that should NOT be cached long. I use WordPress for my blog, and I exclude paths containing things like wp-admin, wp-json, cron… Then, select “Ignore cache-control header,” and use this TTL in the Edge TTL section. And finally, select how long you want to cache. Longer is better because longer means most of your site content, including long-tail content that doesn’t get consistent traffic, will also be cached at the edge. I started with 1 day, then 1 week, then I tried 1 month, but then had some pages stuck in the cache too long and dialed it back to 1 week as my sweet spot. Even if you’re not using Cloudflare, I’m sure there is an equivalent of this in your CDN provider. What Is the Impact on Page Speed? After the change, I saw a big drop (like 90% reduced load) in my server’s load. It meant CDN was doing what it was supposed to do. It’s one of the positive side effects of doing higher cache offload to CDN, to be able to scale higher traffic without needing powerful hosting resources. My Time-To-First-Byte decreased (improved) 70%, coming from shy of 500ms down to 100–160ms range 🤯 More importantly, the real user experience on the page became even more mind-blowing because things became super snappy. Click click click, bam bam bam, nothing was in a visible loading state anymore. Even if metrics didn’t move, I am super happy with this aspect of the change. 🤯🤯🤩 I got my Cloudflare Web Analytics email and noticed almost all Web Vitals moved positively at least 30% improvement. I wasn’t expecting other Web vitals like CLS and LCP to be directly impacted (or impacted as much as they did). But it makes sense. When the assets load much faster like this, the “wait time” (or blocking time) goes down, therefore, the layout shift or the largest paint goes down. SEO Impact It’s a well-known fact that Google takes your “core web vitals” into account when determining your ranking in the search results. This change has more impact on crawlers than you think. Because most of the time, crawlers’ requests are the ones that hit “cache cold” pages. It means Google (or other search engines) is reading your site holistically way more than your real users. Imagine every single article you wrote. There is no user who reads every single one of them — Google does 🙂 (and does it regularly). When a crawler tries to visit a page that nobody read in a long time, its request will have cache-miss more likely than cache-hit, so it will “wait” longer for your web server to render the page. When you put yourself in the crawler’s shoes, imagine you try to read 10,000 articles/pages on a site over a day or two period (maybe it takes longer, who knows…). Now, consider the percentage of those pages that will have to be rendered, or served from the CDN cache. The more pages Google sees “slow”, it will think your whole site is slow. This is where the real value of super-long TTLs comes in. Especially if you combine that with serve-stale-while-revalidate (SSWR) which most CDNs automatically do (if not, I’m sure there is a setting you can enable these together). SSWR, with a super-long TTL (like 7 days, or more), basically creates an infinite loop of “always cached” scenarios. And with that, your crawler traffic gets served from the cache (at cost/risk of “stale content” which is OK in the vast majority of use cases), and directly increases your site’s overall speed score and, therefore your SEO scores. Content Freshness There is one caveat though, which is content freshness. When you bump the Edge TTL up to multi-day TTLs like I did, you need to make sure your CMS/site is nicely integrated with your CDN’s cache clear systems, in the case you make updates. Two scenarios: You update existing content (like fixing a typo or changing the cover image of a post); the change should be reflected on the content’s detail page right away. You update existing content (like fixing a typo or changing the cover image of a post); the change should be reflected on the content’s detail page right away. You publish new content, so the new content is supposed to show up in common places like your homepage. You publish new content, so the new content is supposed to show up in common places like your homepage. You can use your CDN’s cache clear UI or APIs to trigger “purge” on URLs you think it’s impacted (homepage, section pages, etc.), or highly visible pages like the homepage can be configured with a lower TTL in a separate cache rule set. I use WordPress for my content management system and Cloudflare has a WordPress plugin to listen to publish/update hooks to trigger these cache clear nicely. Another way to think about this is to find the balance. What is the “staleness” you can tolerate on a page? Let’s say another article detail page showing “recent articles” or “related articles” sections to NOT show your most recent article there. As long as that time length is not something you can’t afford, cache longer to achieve better site/page performance.

How to Tweak CDN/Edge TTL to Radically Improve Site Performance (and SEO): A Quick Guide

QuickSwap, a multi-chain decentralized exchange (DEX), announced its expansion to Ethereum through integration with Orbs Liquidity Hub, marking a strategic move in the DEX ecosystem's evolution. Following a successful governance vote, QuickSwap will utilize Orbs technology to source and manage all liquidity for its Ethereum operations. The integration enables QuickSwap to access both on-chain and off-chain liquidity sources, potentially enhancing trading efficiency on the platform. The move builds upon QuickSwap's existing relationship with Orbs, following earlier implementations of dTWAP and dLIMIT protocols on the Polygon network. These protocols have enabled advanced trading features such as dollar-cost averaging and large trade splitting capabilities. Technical Implementation The Orbs Liquidity Hub operates through a competitive solver network that sources liquidity from various channels. When users initiate trades, these solvers compete to fulfill orders using multiple sources, including automated market maker (AMM) pools and private inventory. The system also provides API access, enabling market makers to participate in trade execution. The Hub's infrastructure integrates with established platforms including ParaSwap and Odos, creating a broader liquidity network. This architecture allows for real-time competition among liquidity providers, potentially leading to more efficient price discovery. Market Impact The integration represents a significant development in QuickSwap's multi-chain strategy. Originally launched on Polygon in October 2021 to address Ethereum's high gas fees, QuickSwap has evolved to serve multiple blockchain networks. This expansion to Ethereum using Orbs technology signals a shift in DEX infrastructure development. "The governance vote demonstrates strong community support for this technical integration," noted an industry analyst familiar with the development. "This could influence how other DEXs approach cross-chain expansion and liquidity management." Technical Framework The implementation includes several key components: Complete integration of Orbs Liquidity Hub for Ethereum operations


Competitive solver network for order fulfillment


API accessibility for professional trading entities


Integration with existing liquidity aggregation platforms The system maintains compatibility with both EVM (Ethereum Virtual Machine) and non-EVM smart contracts, enabling broader market access while preserving existing liquidity pools. Market Context This development occurs amid increasing focus on cross-chain interoperability and liquidity efficiency in decentralized finance. The integration potentially positions QuickSwap to address historical challenges in DEX operations, including liquidity fragmentation and trading efficiency. Market participants will likely monitor several metrics to evaluate the integration's effectiveness, including trading volumes, price efficiency, and cross-chain transaction performance. The implementation's success could influence future developments in DEX architecture and multi-chain trading solutions. Don’t forget to like and share the story! Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR QuickSwap , a multi-chain decentralized exchange (DEX), announced its expansion to Ethereum through integration with Orbs Liquidity Hub, marking a strategic move in the DEX ecosystem's evolution. Following a successful governance vote, QuickSwap will utilize Orbs technology to source and manage all liquidity for its Ethereum operations. The integration enables QuickSwap to access both on-chain and off-chain liquidity sources, potentially enhancing trading efficiency on the platform. QuickSwap The move builds upon QuickSwap's existing relationship with Orbs , following earlier implementations of dTWAP and dLIMIT protocols on the Polygon network. These protocols have enabled advanced trading features such as dollar-cost averaging and large trade splitting capabilities. Orbs Technical Implementation The Orbs Liquidity Hub operates through a competitive solver network that sources liquidity from various channels. When users initiate trades, these solvers compete to fulfill orders using multiple sources, including automated market maker (AMM) pools and private inventory. The system also provides API access, enabling market makers to participate in trade execution. The Hub's infrastructure integrates with established platforms including ParaSwap and Odos, creating a broader liquidity network. This architecture allows for real-time competition among liquidity providers, potentially leading to more efficient price discovery. Market Impact The integration represents a significant development in QuickSwap's multi-chain strategy. Originally launched on Polygon in October 2021 to address Ethereum's high gas fees, QuickSwap has evolved to serve multiple blockchain networks. This expansion to Ethereum using Orbs technology signals a shift in DEX infrastructure development. "The governance vote demonstrates strong community support for this technical integration," noted an industry analyst familiar with the development. "This could influence how other DEXs approach cross-chain expansion and liquidity management." Technical Framework The implementation includes several key components: Complete integration of Orbs Liquidity Hub for Ethereum operations Competitive solver network for order fulfillment API accessibility for professional trading entities Integration with existing liquidity aggregation platforms Complete integration of Orbs Liquidity Hub for Ethereum operations Complete integration of Orbs Liquidity Hub for Ethereum operations Competitive solver network for order fulfillment Competitive solver network for order fulfillment API accessibility for professional trading entities API accessibility for professional trading entities Integration with existing liquidity aggregation platforms Integration with existing liquidity aggregation platforms The system maintains compatibility with both EVM (Ethereum Virtual Machine) and non-EVM smart contracts, enabling broader market access while preserving existing liquidity pools. Market Context This development occurs amid increasing focus on cross-chain interoperability and liquidity efficiency in decentralized finance. The integration potentially positions QuickSwap to address historical challenges in DEX operations, including liquidity fragmentation and trading efficiency. Market participants will likely monitor several metrics to evaluate the integration's effectiveness, including trading volumes, price efficiency, and cross-chain transaction performance. The implementation's success could influence future developments in DEX architecture and multi-chain trading solutions. Don’t forget to like and share the story! Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program . HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR Vested Interest Disclosure: business blogging program business blogging program

QuickSwap Expands to Ethereum Network Through Orbs Liquidity Hub Integration

This is not a fable. This story actually happened in front of my bewildered eyes. Armed with a custom GPT model, an analyst sought to streamline the daunting task of querying voluminous financial data. It was, at first glance, a stroke of genius—a breakthrough tool designed to make data analysis accessible to those without a background in coding. No more grappling with Python or SQL—just the power of natural language at your fingertips. The potential was enormous. But what started as a promising innovation took a bizarre and disappointing turn when the analyst’s own rigidity stifled what could have been an even greater leap forward. The project had undeniable merit. By uploading a complex dataset on historical spending and budget allocations into a finely-tuned GPT model, the analyst had transformed a traditionally opaque subject into something approachable and understandable. The model could answer questions in plain English, making it possible for anyone to interrogate budget data without needing a technical skillset. It was a tool that promised to democratize data analysis, offering a window into public spending that had previously been closed to most. But the excitement in the room dimmed when a critical question was raised: How do you know if the chatbot is accurate? With surprising naïveté, the analyst replied that it was impossible for the bot to be wrong. “It’s generating Python code,” he confidently stated, as though the act of generating code automatically ensured the validity of the results. It was a moment of dismay for those watching. The assertion was not only technically flawed but exposed a fundamental misunderstanding of how AI and coding work. Any experienced data professional understands that generating code is not the same as ensuring its correctness. Python code can easily harbor logical flaws, even if it’s syntactically perfect. The model, in interpreting and responding to the uploaded data, could misrepresent figures, make incorrect assumptions, or simply produce erroneous outputs due to the quality of the data it was trained on. Yet, the analyst stood firm, unable to consider that his model might produce mistakes—a kind of tunnel vision that can be dangerous in data-driven work. But that wasn’t where the real disappointment lay. After all, everyone can misjudge their own creations at times. The more troubling moment came when someone suggested an enhancement that could have elevated the project: Why not use the chatbot to generate thought-provoking questions about the budget? If the model had been trained on all this data, surely it could be used to stimulate new lines of inquiry and suggest areas that warranted deeper scrutiny. The analyst’s reaction was, frankly, perplexing. He flatly rejected the suggestion, insisting that any questions the chatbot might generate would be random and lack relevance. It was as though he had completely forgotten the context he’d given the model, which made it perfectly capable of producing insightful, data-driven questions. His view of the model was limited to being a data query tool—nothing more. Instead of seeing AI as a partner in analysis, he closed his mind, refusing to entertain the idea that it could be a collaborator in generating new ideas. It was a turning point—the analyst had created something that could revolutionize the way people interacted with data, only to refuse to let it evolve beyond his own narrow vision. He had built a car but refused to consider driving it anywhere new. The GPT model, which could have empowered non-technical users to explore the budget, analyze trends, and even brainstorm innovative questions, was reduced to a glorified search engine. In shutting down the very possibility of using AI as a tool for exploration, the analyst effectively undermined the transformative potential of his own project. What makes this turn of events truly disappointing is not just the missed opportunity but what it says about our broader mindset in the face of new technologies. There is a tendency to see AI as a mere extension of what we already do—a faster calculator, a more efficient script writer, a streamlined data query interface. In confining AI to such narrow applications, we do it a disservice, but more importantly, we limit ourselves. We fail to see it as a tool that can help us think, challenge our assumptions and even suggest avenues we might not have considered. This data analyst got far, indeed, with his custom GPT model. He demonstrated how new technology can lower barriers, allowing more people to engage with complex datasets. But then, just as he was poised to break through to something truly revolutionary, his brain shut down. He stopped innovating. He refused to imagine. And he dismissed AI’s greatest asset: its ability to generate new perspectives, new connections, and new questions that humans might never have formulated on their own. The lesson here is clear. In the era of AI, the greatest challenge is not building more capable models—it’s maintaining an open mind. As we push the boundaries of technology, we must ensure that we don’t box ourselves in with outdated thinking. Because when we stop dreaming and exploring, even the most powerful AI can’t help us break new ground. About Me: 25+ year IT veteran combining data, AI, risk management, strategy, and education. 4x hackathon winner and social impact from data advocate. Currently working to jumpstart the AI workforce in the Philippines. Learn more about me here: https://docligot.com This is not a fable. This story actually happened in front of my bewildered eyes. Armed with a custom GPT model, an analyst sought to streamline the daunting task of querying voluminous financial data. It was, at first glance, a stroke of genius—a breakthrough tool designed to make data analysis accessible to those without a background in coding. No more grappling with Python or SQL—just the power of natural language at your fingertips. The potential was enormous. But what started as a promising innovation took a bizarre and disappointing turn when the analyst’s own rigidity stifled what could have been an even greater leap forward. The project had undeniable merit. By uploading a complex dataset on historical spending and budget allocations into a finely-tuned GPT model, the analyst had transformed a traditionally opaque subject into something approachable and understandable. The model could answer questions in plain English, making it possible for anyone to interrogate budget data without needing a technical skillset. It was a tool that promised to democratize data analysis, offering a window into public spending that had previously been closed to most. But the excitement in the room dimmed when a critical question was raised: How do you know if the chatbot is accurate? With surprising naïveté, the analyst replied that it was impossible for the bot to be wrong. “It’s generating Python code,” he confidently stated, as though the act of generating code automatically ensured the validity of the results. It was a moment of dismay for those watching. The assertion was not only technically flawed but exposed a fundamental misunderstanding of how AI and coding work. Any experienced data professional understands that generating code is not the same as ensuring its correctness. Python code can easily harbor logical flaws, even if it’s syntactically perfect. The model, in interpreting and responding to the uploaded data, could misrepresent figures, make incorrect assumptions, or simply produce erroneous outputs due to the quality of the data it was trained on. Yet, the analyst stood firm, unable to consider that his model might produce mistakes—a kind of tunnel vision that can be dangerous in data-driven work. But that wasn’t where the real disappointment lay. After all, everyone can misjudge their own creations at times. The more troubling moment came when someone suggested an enhancement that could have elevated the project: Why not use the chatbot to generate thought-provoking questions about the budget? If the model had been trained on all this data, surely it could be used to stimulate new lines of inquiry and suggest areas that warranted deeper scrutiny. The analyst’s reaction was, frankly, perplexing. He flatly rejected the suggestion, insisting that any questions the chatbot might generate would be random and lack relevance. It was as though he had completely forgotten the context he’d given the model, which made it perfectly capable of producing insightful, data-driven questions. His view of the model was limited to being a data query tool—nothing more. Instead of seeing AI as a partner in analysis, he closed his mind, refusing to entertain the idea that it could be a collaborator in generating new ideas. It was a turning point—the analyst had created something that could revolutionize the way people interacted with data, only to refuse to let it evolve beyond his own narrow vision. He had built a car but refused to consider driving it anywhere new. The GPT model, which could have empowered non-technical users to explore the budget, analyze trends, and even brainstorm innovative questions, was reduced to a glorified search engine. In shutting down the very possibility of using AI as a tool for exploration, the analyst effectively undermined the transformative potential of his own project. What makes this turn of events truly disappointing is not just the missed opportunity but what it says about our broader mindset in the face of new technologies. There is a tendency to see AI as a mere extension of what we already do—a faster calculator, a more efficient script writer, a streamlined data query interface. In confining AI to such narrow applications, we do it a disservice, but more importantly, we limit ourselves. We fail to see it as a tool that can help us think, challenge our assumptions and even suggest avenues we might not have considered. This data analyst got far, indeed, with his custom GPT model. He demonstrated how new technology can lower barriers, allowing more people to engage with complex datasets. But then, just as he was poised to break through to something truly revolutionary, his brain shut down. He stopped innovating. He refused to imagine. And he dismissed AI’s greatest asset: its ability to generate new perspectives, new connections, and new questions that humans might never have formulated on their own. The lesson here is clear. In the era of AI, the greatest challenge is not building more capable models—it’s maintaining an open mind. As we push the boundaries of technology, we must ensure that we don’t box ourselves in with outdated thinking. Because when we stop dreaming and exploring, even the most powerful AI can’t help us break new ground. About Me: 25+ year IT veteran combining data, AI, risk management, strategy, and education. 4x hackathon winner and social impact from data advocate. Currently working to jumpstart the AI workforce in the Philippines. Learn more about me here: https://docligot.com About Me: 25+ year IT veteran combining data, AI, risk management, strategy, and education. 4x hackathon winner and social impact from data advocate. Currently working to jumpstart the AI workforce in the Philippines. Learn more about me here: https://docligot.com

Analyst Gets Far With Custom GPT, But Then Quickly Surrenders

DolphinScheduler is a powerful open-source distributed task scheduling system widely used in the big data field for managing complex workflows. This article will provide a detailed guide on how to install and configure DolphinScheduler using Docker Compose, allowing you to quickly set up and start using the system. 1. Environment Preparation First, ensure that Docker and Docker Compose are installed on your system. Docker is an open-source containerization platform that allows developers to package applications and their dependencies into containers, providing high portability and consistency. Docker Compose is a tool for defining and managing multi-container applications. It uses a YAML file to configure the services and provides a single command to start or stop those services. 1.1 Verifying Docker and Docker Compose Installation You can verify if Docker and Docker Compose are installed correctly using the following commands: docker --versiondocker-compose --version If you see the version information, the installation was successful. 2. Downloading the DolphinScheduler Docker Compose Configuration File Before installing and running DolphinScheduler, you need to obtain its Docker Compose configuration file. This file defines the runtime environment for DolphinScheduler and its dependent services. Follow these steps to get the configuration file: 2.1 Clone the DolphinScheduler Project First, use Git to clone the official DolphinScheduler repository: git clone https://github.com/apache/dolphinscheduler.git This will download the DolphinScheduler project to your local machine. Next, navigate to the project directory: cd dolphinscheduler/docker In this directory, you will find a file named docker-compose.yml, which is the core configuration file for Docker Compose. 3. Configuring the Docker Compose File The docker-compose.yml file defines the services needed to run DolphinScheduler, including a MySQL database, ZooKeeper cluster, and DolphinScheduler's Master and Worker nodes. You can modify this file as needed to adjust the configuration of each service. 3.1 Overview of the Docker Compose File The docker-compose.yml file has the following basic structure: version: '3.1'
services:
  zookeeper:
    image: zookeeper:3.5.6
    ports:
      - "2181:2181"
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: dolphinscheduler
    ports:
      - "3306:3306"
  dolphinscheduler-master:
    image: apache/dolphinscheduler:latest
    depends_on:
      - mysql
      - zookeeper
    ports:
      - "12345:12345"
    environment:
      - DOLPHINSCHEDULER_OPTS="-Xms512m -Xmx512m"
  dolphinscheduler-worker:
    image: apache/dolphinscheduler:latest
    depends_on:
      - dolphinscheduler-master
    environment:
      - DOLPHINSCHEDULER_OPTS="-Xms512m -Xmx512m" In this configuration file: zookeeper: Responsible for cluster coordination and service discovery.
mysql: Stores the metadata for DolphinScheduler.
dolphinscheduler-master: The master node responsible for scheduling and managing tasks.
dolphinscheduler-worker: The worker node responsible for executing tasks. 4.Starting DolphinScheduler Once the docker-compose.yml file is configured correctly, you can start DolphinScheduler using Docker Compose: docker-compose up -d This command will start all the services defined in the docker-compose.yml file in the background. You can check the status of the services with the following command: docker-compose ps If all services are listed as Up, DolphinScheduler has been successfully started. 5.Configuring DolphinScheduler 5.1 Initial Setup Once started, you can access DolphinScheduler’s web UI through a browser. By default, the access URL is: http://localhost:12345 At the login screen, use the default admin credentials (username: admin, password: admin). After logging in, you may want to change the default password to enhance system security. 5.2 Creating Projects and Tasks In the web UI, you can create projects and define tasks. DolphinScheduler supports various task types such as Shell, Python, and SQL. You can create workflows by dragging and dropping tasks and setting dependencies between them. 5.3 System Monitoring and Log Management DolphinScheduler offers rich monitoring and logging features. Users can view task execution statuses, monitor cluster health in real-time, and access detailed execution logs, which help debug and optimize workflows. 6.Common Issues and Solutions During usage, you may encounter some issues. Below are common problems and their solutions. 6.1 Service Startup Failures If a service fails to start, you can check the logs to diagnose the issue using the following command: docker-compose logs <service_name> For example: docker-compose logs dolphinscheduler-master The log information can help identify errors such as database connection failures or port conflicts. 6.2 Database Connection Issues If there are database connection failures during startup, it may be due to the MySQL service not starting in time. In this case, try restarting DolphinScheduler manually: docker-compose restart dolphinscheduler-master dolphinscheduler-worker 7.Advantages and Use Cases of DolphinScheduler DolphinScheduler excels in big data processing and ETL task scheduling. Some key advantages include: User-Friendly Interface: Its graphical interface makes task management and monitoring easy, lowering the barrier to entry.
Flexible Task Dependency Management: It allows defining complex task dependencies, making scheduling more efficient.
High Scalability and Availability: Its distributed architecture is suitable for large-scale data processing. 8.Conclusion By following the above steps, you have successfully installed and configured DolphinScheduler using Docker Compose. Its powerful features and flexible configuration make it an ideal choice for distributed task scheduling. Whether for enterprise-level big data processing or small-to-medium-sized data integration projects, DolphinScheduler is a reliable solution. If you encounter issues during usage, you can refer to DolphinScheduler’s official documentation or community resources for more detailed technical support. With continued learning and exploration, you will be able to fully leverage DolphinScheduler’s potential, significantly improving your workflow management. DolphinScheduler is a powerful open-source distributed task scheduling system widely used in the big data field for managing complex workflows. This article will provide a detailed guide on how to install and configure DolphinScheduler using Docker Compose, allowing you to quickly set up and start using the system. 1. Environment Preparation First, ensure that Docker and Docker Compose are installed on your system. Docker is an open-source containerization platform that allows developers to package applications and their dependencies into containers, providing high portability and consistency. Docker Compose is a tool for defining and managing multi-container applications. It uses a YAML file to configure the services and provides a single command to start or stop those services. Docker 1.1 Verifying Docker and Docker Compose Installation You can verify if Docker and Docker Compose are installed correctly using the following commands: docker --versiondocker-compose --version docker --versiondocker-compose --version If you see the version information, the installation was successful. 2. Downloading the DolphinScheduler Docker Compose Configuration File Before installing and running DolphinScheduler, you need to obtain its Docker Compose configuration file. This file defines the runtime environment for DolphinScheduler and its dependent services. Follow these steps to get the configuration file: 2.1 Clone the DolphinScheduler Project First, use Git to clone the official DolphinScheduler repository: git clone https://github.com/apache/dolphinscheduler.git git clone https://github.com/apache/dolphinscheduler.git This will download the DolphinScheduler project to your local machine. Next, navigate to the project directory: cd dolphinscheduler/docker cd dolphinscheduler/docker In this directory, you will find a file named docker-compose.yml , which is the core configuration file for Docker Compose. docker-compose.yml 3. Configuring the Docker Compose File The docker-compose.yml file defines the services needed to run DolphinScheduler, including a MySQL database, ZooKeeper cluster, and DolphinScheduler's Master and Worker nodes. You can modify this file as needed to adjust the configuration of each service. docker-compose.yml 3.1 Overview of the Docker Compose File The docker-compose.yml file has the following basic structure: docker-compose.yml version: '3.1'
services:
  zookeeper:
    image: zookeeper:3.5.6
    ports:
      - "2181:2181"
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: dolphinscheduler
    ports:
      - "3306:3306"
  dolphinscheduler-master:
    image: apache/dolphinscheduler:latest
    depends_on:
      - mysql
      - zookeeper
    ports:
      - "12345:12345"
    environment:
      - DOLPHINSCHEDULER_OPTS="-Xms512m -Xmx512m"
  dolphinscheduler-worker:
    image: apache/dolphinscheduler:latest
    depends_on:
      - dolphinscheduler-master
    environment:
      - DOLPHINSCHEDULER_OPTS="-Xms512m -Xmx512m" version: '3.1'
services:
  zookeeper:
    image: zookeeper:3.5.6
    ports:
      - "2181:2181"
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: dolphinscheduler
    ports:
      - "3306:3306"
  dolphinscheduler-master:
    image: apache/dolphinscheduler:latest
    depends_on:
      - mysql
      - zookeeper
    ports:
      - "12345:12345"
    environment:
      - DOLPHINSCHEDULER_OPTS="-Xms512m -Xmx512m"
  dolphinscheduler-worker:
    image: apache/dolphinscheduler:latest
    depends_on:
      - dolphinscheduler-master
    environment:
      - DOLPHINSCHEDULER_OPTS="-Xms512m -Xmx512m" In this configuration file: In this configuration file: zookeeper: Responsible for cluster coordination and service discovery. mysql: Stores the metadata for DolphinScheduler. dolphinscheduler-master: The master node responsible for scheduling and managing tasks. dolphinscheduler-worker: The worker node responsible for executing tasks. zookeeper: Responsible for cluster coordination and service discovery. mysql: Stores the metadata for DolphinScheduler. dolphinscheduler-master: The master node responsible for scheduling and managing tasks. dolphinscheduler-worker: The worker node responsible for executing tasks. 4.Starting DolphinScheduler Once the docker-compose.yml file is configured correctly, you can start DolphinScheduler using Docker Compose: docker-compose.yml docker-compose up -d docker-compose up -d This command will start all the services defined in the docker-compose.yml file in the background. You can check the status of the services with the following command: docker-compose.yml docker-compose ps docker-compose ps If all services are listed as Up, DolphinScheduler has been successfully started. 5.Configuring DolphinScheduler 5.1 Initial Setup Once started, you can access DolphinScheduler’s web UI through a browser. By default, the access URL is: http://localhost:12345 http://localhost:12345 At the login screen, use the default admin credentials (username: admin , password: admin ). After logging in, you may want to change the default password to enhance system security. admin admin 5.2 Creating Projects and Tasks In the web UI, you can create projects and define tasks. DolphinScheduler supports various task types such as Shell, Python, and SQL. You can create workflows by dragging and dropping tasks and setting dependencies between them. 5.3 System Monitoring and Log Management DolphinScheduler offers rich monitoring and logging features. Users can view task execution statuses, monitor cluster health in real-time, and access detailed execution logs, which help debug and optimize workflows. 6.Common Issues and Solutions During usage, you may encounter some issues. Below are common problems and their solutions. 6.1 Service Startup Failures If a service fails to start, you can check the logs to diagnose the issue using the following command: docker-compose logs <service_name> docker-compose logs <service_name> For example: docker-compose logs dolphinscheduler-master docker-compose logs dolphinscheduler-master The log information can help identify errors such as database connection failures or port conflicts. 6.2 Database Connection Issues If there are database connection failures during startup, it may be due to the MySQL service not starting in time. In this case, try restarting DolphinScheduler manually: docker-compose restart dolphinscheduler-master dolphinscheduler-worker docker-compose restart dolphinscheduler-master dolphinscheduler-worker 7.Advantages and Use Cases of DolphinScheduler DolphinScheduler excels in big data processing and ETL task scheduling. Some key advantages include: User-Friendly Interface: Its graphical interface makes task management and monitoring easy, lowering the barrier to entry. Flexible Task Dependency Management: It allows defining complex task dependencies, making scheduling more efficient. High Scalability and Availability: Its distributed architecture is suitable for large-scale data processing. User-Friendly Interface: Its graphical interface makes task management and monitoring easy, lowering the barrier to entry. Flexible Task Dependency Management: It allows defining complex task dependencies, making scheduling more efficient. High Scalability and Availability: Its distributed architecture is suitable for large-scale data processing. 8.Conclusion By following the above steps, you have successfully installed and configured DolphinScheduler using Docker Compose. Its powerful features and flexible configuration make it an ideal choice for distributed task scheduling. Whether for enterprise-level big data processing or small-to-medium-sized data integration projects, DolphinScheduler is a reliable solution. If you encounter issues during usage, you can refer to DolphinScheduler’s official documentation or community resources for more detailed technical support. With continued learning and exploration, you will be able to fully leverage DolphinScheduler’s potential, significantly improving your workflow management.

Quick Start Guide for DolphinScheduler: Installation and Configuration Using Docker Compose

The TechBeat: Lumoz's Quidditch Testnet Ends Successfully—Mainnet Launch Expected in Q4! (10/12/2024)

The TechBeat: Lumoz's Quidditch Testnet Ends Successfully—Mainnet Launch Expected in Q4! (10/10/2024)

The TechBeat: Lumoz's Quidditch Testnet Ends Successfully—Mainnet Launch Expected in Q4! (10/8/2024)

The Rails World 2024 conference ended last week, and a lot of new components of the Rails ecosystem were released during it including Kamal 2. I decided to make some preparations for the upcoming changes. In March 2024, the Basecamp team released Thruster, a small, Go-based proxy server for Rails. While the original idea of Thruster was to provide the ability to build production-ready Rails applications from a single container for the ONCE project, it will fit perfectly into the Kamal ecosystem. Isn’t It a Redundancy? Wait? Another proxy server? Why do we need it? Allow me to explain. It doesn’t matter whether we use Traefik with Kamal v1 or Kamal-proxy with Kamal v2; inside the container, we still run Puma (or any other Ruby application server) that serves requests to the application. Besides this, Puma is also responsible for serving application assets – images, stylesheets, JavaScript files, etc. – to the clients. Before Kamal came into the scene, we usually had Nginx in our infrastructure schema. Nginx is a classic web server that can serve static files efficiently. Unfortunately, it is not adapted to container-based setups as you need to manage its configuration via a config file. However, without Nginx, Puma is not the best choice to serve static files. This is where Thruster comes into play. It wraps the Puma instance and efficiently serves static files with X-Sendfile acceleration, while Puma is responsible for the dynamic content. Thruster also provides GZip compression which was available in Traefik via middleware but won’t exist in kamal-proxy. GZip compression plays a crucial role in optimizing web performance by significantly reducing the size of files transmitted between a server and a client. By compressing assets like HTML, CSS, and JavaScript, GZIP decreases bandwidth usage and accelerates the loading times of web pages, providing users with a faster, more seamless browsing experience. This not only enhances user satisfaction but also improves search engine rankings, as faster websites tend to rank higher in search results. Additionally, reducing the size of data transfers lightens the load on servers, allowing them to handle more requests efficiently and lowering hosting costs. A reasonable question would be “Why I cannot do a GZIP compression in Rails?” Technically, you can with Rack::Deflater. But since Thruster is already responsible for serving public assets, it can also efficiently handle compression. Besides compression, Thruster also provides basic HTTP caching of public assets and HTTP/2 support. With Thruster, your Rails application can be treated as a black box, which can serve any kind of request efficiently. How to Use Thruster is straightforward to use if you’re already using Puma. First, you need to add Thruster to your Gemfile: # Gemfile

gem 'thruster' Run bundle install, and you are ready to go. Since Thruster is written in Go, the platform-specific binary will be downloaded and installed with the gem. I always create binstubs to have all the necessary commands in one place: $ bundle binstubs thruster By default, Thruster will listen on port 80, while Puma will stay on port 3000. Knowing this, we should update our application Dockerfile accordingly. I assume here that your application is already dockerized. I replaced the port that is getting exposed from 3000 to 80 and added ./bin/thrust to the default command. # Dockerfile

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start server via Thruster by default, this can be overwritten at runtime
EXPOSE 80
CMD ["./bin/thrust", "./bin/rails", "server"] The last change is to update ./bin/docker-entrypoint script. I always try to keep it as close to the original Rails template as possible. Below is the final version of the script. #!/bin/bash -e

# If running the rails server then create or migrate existing database
if [ "${@: -2:1}" == "./bin/rails" ] && [ "${@: -1:1}" == "server" ]; then
  ./bin/rails db:prepare
fi

exec "${@}" That is all! Thanks to the Traefik container-based configuration, it will read the exposed port from the container and route the traffic accordingly after you deploy the changes. After deploy is finished, you can log in to the container and check if Thruster is running: rails@docker:~$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
rails          1  0.0  0.3 1232848 13124 ?       Ssl  09:26   0:06 /usr/local/bundle/ruby/3.3.0/gems/thruster-0.1.8-x86_64-linux/exe/x86_64-linux/thrust ./bin/rails server Summary Since there are no visible cons of using Thruster in your Rails application, I highly recommend using it. It can improve the performance of your application and reduce the load on the server. It is also a good idea to use it as a preparation for the upcoming Kamal 2 release. The Rails World 2024 conference ended last week, and a lot of new components of the Rails ecosystem were released during it including Kamal 2. I decided to make some preparations for the upcoming changes. In March 2024, the Basecamp team released Thruster , a small, Go-based proxy server for Rails. While the original idea of Thruster was to provide the ability to build production-ready Rails applications from a single container for the ONCE project, it will fit perfectly into the Kamal ecosystem. Thruster Isn’t It a Redundancy? Wait? Another proxy server? Why do we need it? Allow me to explain. It doesn’t matter whether we use Traefik with Kamal v1 or Kamal-proxy with Kamal v2; inside the container, we still run Puma (or any other Ruby application server) that serves requests to the application. Besides this, Puma is also responsible for serving application assets – images, stylesheets, JavaScript files, etc. – to the clients. Before Kamal came into the scene, we usually had Nginx in our infrastructure schema. Nginx is a classic web server that can serve static files efficiently. Unfortunately, it is not adapted to container-based setups as you need to manage its configuration via a config file. However, without Nginx, Puma is not the best choice to serve static files. This is where Thruster comes into play. It wraps the Puma instance and efficiently serves static files with X-Sendfile acceleration, while Puma is responsible for the dynamic content. Thruster also provides GZip compression which was available in Traefik via middleware but won’t exist in kamal-proxy. GZip compression plays a crucial role in optimizing web performance by significantly reducing the size of files transmitted between a server and a client. By compressing assets like HTML, CSS, and JavaScript, GZIP decreases bandwidth usage and accelerates the loading times of web pages, providing users with a faster, more seamless browsing experience. via middleware This not only enhances user satisfaction but also improves search engine rankings, as faster websites tend to rank higher in search results. Additionally, reducing the size of data transfers lightens the load on servers, allowing them to handle more requests efficiently and lowering hosting costs. A reasonable question would be “Why I cannot do a GZIP compression in Rails?” Technically, you can with Rack::Deflater . But since Thruster is already responsible for serving public assets, it can also efficiently handle compression. Rack::Deflater Besides compression, Thruster also provides basic HTTP caching of public assets and HTTP/2 support. With Thruster, your Rails application can be treated as a black box, which can serve any kind of request efficiently. With Thruster, your Rails application can be treated as a black box, which can serve any kind of request efficiently. How to Use Thruster is straightforward to use if you’re already using Puma. First, you need to add Thruster to your Gemfile: # Gemfile

gem 'thruster' # Gemfile

gem 'thruster' Run bundle install, and you are ready to go. Since Thruster is written in Go, the platform-specific binary will be downloaded and installed with the gem. bundle install, I always create binstubs to have all the necessary commands in one place: $ bundle binstubs thruster $ bundle binstubs thruster By default, Thruster will listen on port 80, while Puma will stay on port 3000. Knowing this, we should update our application Dockerfile accordingly. I assume here that your application is already dockerized. I replaced the port that is getting exposed from 3000 to 80 and added ./bin/thrust to the default command. Dockerfile ./bin/thrust # Dockerfile

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start server via Thruster by default, this can be overwritten at runtime
EXPOSE 80
CMD ["./bin/thrust", "./bin/rails", "server"] # Dockerfile

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start server via Thruster by default, this can be overwritten at runtime
EXPOSE 80
CMD ["./bin/thrust", "./bin/rails", "server"] The last change is to update ./bin/docker-entrypoint script. I always try to keep it as close to the original Rails template as possible. ./bin/docker-entrypoint original Rails template Below is the final version of the script. #!/bin/bash -e

# If running the rails server then create or migrate existing database
if [ "${@: -2:1}" == "./bin/rails" ] && [ "${@: -1:1}" == "server" ]; then
  ./bin/rails db:prepare
fi

exec "${@}" #!/bin/bash -e

# If running the rails server then create or migrate existing database
if [ "${@: -2:1}" == "./bin/rails" ] && [ "${@: -1:1}" == "server" ]; then
  ./bin/rails db:prepare
fi

exec "${@}" That is all! Thanks to the Traefik container-based configuration, it will read the exposed port from the container and route the traffic accordingly after you deploy the changes. After deploy is finished, you can log in to the container and check if Thruster is running: rails@docker:~$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
rails          1  0.0  0.3 1232848 13124 ?       Ssl  09:26   0:06 /usr/local/bundle/ruby/3.3.0/gems/thruster-0.1.8-x86_64-linux/exe/x86_64-linux/thrust ./bin/rails server rails@docker:~$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
rails          1  0.0  0.3 1232848 13124 ?       Ssl  09:26   0:06 /usr/local/bundle/ruby/3.3.0/gems/thruster-0.1.8-x86_64-linux/exe/x86_64-linux/thrust ./bin/rails server Summary Since there are no visible cons of using Thruster in your Rails application, I highly recommend using it. It can improve the performance of your application and reduce the load on the server. It is also a good idea to use it as a preparation for the upcoming Kamal 2 release.

Rails Thruster 101: A Quick Guide

Dear Lumozers, We are thrilled to announce that the final round of the Lumoz Quidditch incentive testnet officially concluded on September 27 at 16:00 (UTC+8). This event, which began on August 27, lasted a month and attracted enthusiastic participation from regular users, outstanding project teams, zkVerifier nodes, developers, and more. Today, we are excited to share the remarkable achievements of the Quidditch testnet and provide details on the upcoming points redemption process, ensuring a smooth transition from the testnet to the future mainnet. Testnet Data Performance: Regular User Participation: 1,000,000+


Ecosystem Project Participation: 30+


Nodes Operated: 750+


License Staking: 58,000+


Verifications Submitted: 7,230,356


Total Community Size: 1,600,000+ The Quidditch incentive testnet introduced the Lumoz-developed Quidditch Bot TG game, allowing participants to enjoy the game while sharing a prize pool of 50 million esMOZ tokens. The event received support from over 30 top ecosystem projects, including OKX Wallet and Bitget Wallet, which provided generous rewards and designed unique tasks, greatly enhancing the user experience. In the core part of the event, participants operated verification nodes by staking tokens, experiencing the decentralized nature of the network firsthand. At the end of the event, the number of participating nodes reached 752, with 58,183 licenses staked and a total of 154,414 participants in the staking tests. The total number of verifications submitted was 7,230,356. These figures clearly demonstrate the stability and scalability of the Lumoz network. About Points Inquiry and Redemption This event released a total of 50 million points, with sources including points earned by exchanging through the Golden Snitch with magic stones, points from participating in ecosystem project tasks, and points earned from advanced tasks like node testing. We will distribute the points fairly based on participation, contribution, and task completion, ensuring that every point is treated fairly and transparently. Currently, participants in the game can check their points on the leaderboard within the Bot. Please note that the statistics for points earned from the other 25 ecosystem activities are still being finalized by the team and are expected to be completed by October 10. At that time, all users will be able to view their cumulative points from various stages via the official website link. Points Inquiry Portal：https://lumoz.org/lumoz-points Points redemption is also a top priority for everyone. According to the official documentation, 50 million points can be exchanged on a 1:1 basis for 50 million esMOZ. Holders of esMOZ will gain the right to participate in Lumoz ecosystem governance. To ensure ecosystem stability, the exchange rules between MOZ and esMOZ will have different ratios for various time periods. esMOZ will also have a reasonable lock-up period, and redemption can be canceled at any time. For detailed information on points distribution and token exchange progress, please stay tuned to Lumoz's social media and Discord community. Mainnet Launch: A New Chapter Awaits Lumoz, as a globally distributed modular computing network, provides users with a powerful, secure, and flexible computing platform. The uniqueness of this architecture not only enables Lumoz to deliver efficient performance but also allows for personalized solutions across various scenarios. In this context, the launch of the final round of the Quidditch testnet is particularly significant. In the first half of this year, Lumoz successfully completed its Pre-A round and strategic financing, totaling $14 million, with a new round of funding valued at up to $300 million. Participating institutions include OKX Ventures, HashKey Capital, KuCoin Ventures, Polygon, IDG Blockchain, and others, reflecting the capital market's optimism and expectations for Lumoz. This also provides Lumoz with stronger financial resources to maintain and innovate its technology and products. With the testnet activities concluded, the team is currently preparing for Lumoz's mainnet launch and TGE. The mainnet will inherit the excellent features of the testnet, including high performance, strong security, and good scalability. At the same time, we plan to deploy and support multiple Layer 2 solutions, further develop existing products like ZKFair and Merlin Chain, and introduce more Layer 2 chains to provide innovative solutions for various industries, driving progress across the entire blockchain ecosystem. Final Thanks and Outlook To date, Lumoz has successfully completed three rounds of testnets: Pre-Alpha, Alpha, and Quidditch. The success of these testnets is undoubtedly due to the contributions of every participant. Your enthusiasm, feedback, and suggestions are invaluable nutrients for Lumoz's growth. We would also like to extend our special thanks to the 200+ ecosystem partners and millions of community users who have supported us since Lumoz's inception. Based on our past successes, we believe that the launch of the Lumoz mainnet and TGE before the end of 2024 will achieve remarkable results! Let us join hands and witness the arrival of the zero-knowledge computing era, creating a bright future for Lumoz together! Dear Lumozers, We are thrilled to announce that the final round of the Lumoz Quidditch incentive testnet officially concluded on September 27 at 16:00 (UTC+8). This event, which began on August 27, lasted a month and attracted enthusiastic participation from regular users, outstanding project teams, zkVerifier nodes, developers, and more. Today, we are excited to share the remarkable achievements of the Quidditch testnet and provide details on the upcoming points redemption process, ensuring a smooth transition from the testnet to the future mainnet. Testnet Data Performance: Regular User Participation: 1,000,000+ Ecosystem Project Participation: 30+ Nodes Operated: 750+ License Staking: 58,000+ Verifications Submitted: 7,230,356 Total Community Size: 1,600,000+ Regular User Participation: 1,000,000+ Regular User Participation: 1,000,000+ Ecosystem Project Participation: 30+ Ecosystem Project Participation: 30+ Nodes Operated: 750+ Nodes Operated: 750+ License Staking: 58,000+ License Staking: 58,000+ Verifications Submitted: 7,230,356 Verifications Submitted: 7,230,356 Total Community Size: 1,600,000+ Total Community Size: 1,600,000+ The Quidditch incentive testnet introduced the Lumoz-developed Quidditch Bot TG game, allowing participants to enjoy the game while sharing a prize pool of 50 million esMOZ tokens. The event received support from over 30 top ecosystem projects, including OKX Wallet and Bitget Wallet, which provided generous rewards and designed unique tasks, greatly enhancing the user experience. In the core part of the event, participants operated verification nodes by staking tokens, experiencing the decentralized nature of the network firsthand. At the end of the event, the number of participating nodes reached 752, with 58,183 licenses staked and a total of 154,414 participants in the staking tests. The total number of verifications submitted was 7,230,356. These figures clearly demonstrate the stability and scalability of the Lumoz network. About Points Inquiry and Redemption This event released a total of 50 million points, with sources including points earned by exchanging through the Golden Snitch with magic stones, points from participating in ecosystem project tasks, and points earned from advanced tasks like node testing. We will distribute the points fairly based on participation, contribution, and task completion, ensuring that every point is treated fairly and transparently. Currently, participants in the game can check their points on the leaderboard within the Bot. Please note that the statistics for points earned from the other 25 ecosystem activities are still being finalized by the team and are expected to be completed by October 10. At that time, all users will be able to view their cumulative points from various stages via the official website link . leaderboard leaderboard the official website link the official website link Points Inquiry Portal ：https://lumoz.org/lumoz-points Points Inquiry Portal Points redemption is also a top priority for everyone. According to the official documentation, 50 million points can be exchanged on a 1:1 basis for 50 million esMOZ. Holders of esMOZ will gain the right to participate in Lumoz ecosystem governance. To ensure ecosystem stability, the exchange rules between MOZ and esMOZ will have different ratios for various time periods. esMOZ will also have a reasonable lock-up period, and redemption can be canceled at any time. For detailed information on points distribution and token exchange progress, please stay tuned to Lumoz's social media and Discord community . Lumoz's social media Lumoz's social media Discord community Discord community Mainnet Launch: A New Chapter Awaits Lumoz, as a globally distributed modular computing network, provides users with a powerful, secure, and flexible computing platform. The uniqueness of this architecture not only enables Lumoz to deliver efficient performance but also allows for personalized solutions across various scenarios. In this context, the launch of the final round of the Quidditch testnet is particularly significant. In the first half of this year, Lumoz successfully completed its Pre-A round and strategic financing, totaling $14 million, with a new round of funding valued at up to $300 million. Participating institutions include OKX Ventures, HashKey Capital, KuCoin Ventures, Polygon, IDG Blockchain, and others, reflecting the capital market's optimism and expectations for Lumoz. This also provides Lumoz with stronger financial resources to maintain and innovate its technology and products. With the testnet activities concluded, the team is currently preparing for Lumoz's mainnet launch and TGE. The mainnet will inherit the excellent features of the testnet, including high performance, strong security, and good scalability. At the same time, we plan to deploy and support multiple Layer 2 solutions, further develop existing products like ZKFair and Merlin Chain, and introduce more Layer 2 chains to provide innovative solutions for various industries, driving progress across the entire blockchain ecosystem. Final Thanks and Outlook To date, Lumoz has successfully completed three rounds of testnets: Pre-Alpha, Alpha, and Quidditch. The success of these testnets is undoubtedly due to the contributions of every participant. Your enthusiasm, feedback, and suggestions are invaluable nutrients for Lumoz's growth. We would also like to extend our special thanks to the 200+ ecosystem partners and millions of community users who have supported us since Lumoz's inception. Based on our past successes, we believe that the launch of the Lumoz mainnet and TGE before the end of 2024 will achieve remarkable results! Let us join hands and witness the arrival of the zero-knowledge computing era, creating a bright future for Lumoz together!

Stories, News & Mentions about QUI

Qui’s Stories on HackerNoon