Show HN: A bidirectional editor for making circuits with code https://ift.tt/X7sq19Y

Show HN: A bidirectional editor for making circuits with code https://ift.tt/bNh9gKU December 23, 2024 at 10:06PM

Show HN: A simple telegram file downloader https://ift.tt/ZSlJvGL

Show HN: A simple telegram file downloader https://ift.tt/DNnAzod December 23, 2024 at 01:24PM

Show HN: I built this website about Sikh History and don't know how code works https://ift.tt/TJdH7LM

Show HN: I built this website about Sikh History and don't know how code works I've been learning about Sikhism and Sikh history recently and, despite having Game of Thrones level drama, I found the resources really lacking and nowhere piecing it all together. I work in a developer adjacent role (ok, I'm a Product Manager) but despite working with software engineers every day I don't really get coding. I see a lot of stuff online about the death of software engineers and wanted to challenge myself to see if I could create something myself. I've been using the free tier of Anthropic's Claude AI, deployed on the free Vercel tier, spent $10 on the domain but not a penny more on anything else. It's super basic but felt good to make something myself and I learned a lot. I'd brick it at the idea of adding anything complex (or even being asked how it all works together) so I'm sure developers are safe for a while yet! https://ift.tt/KzvT6MN December 23, 2024 at 10:31AM

Show HN: Ephemeral VMs in 1 Microsecond https://ift.tt/b4U3t96

Show HN: Ephemeral VMs in 1 Microsecond https://ift.tt/zy0ClE2 December 20, 2024 at 04:13PM

Show HN: Skybear.net – A managed platform automating Synthetic HTTP API testing https://ift.tt/hA1Egno

Show HN: Skybear.net – A managed platform automating Synthetic HTTP API testing Hey folks, I am finally posting a Show HN post for a project I have been working on for several months now, and it's in a state where I already get a lot of value myself, so I am happy to share broadly. The pitch line is: "Skybear.NET is a managed platform automating Synthetic HTTP API testing." At the moment, the main source file format supported for your API tests are Hurl.dev files [1]. Hurl is a CLI tool wrapping `curl` and it's really awesome. At least check that out :) I am not affiliated directly with the Hurl CLI tool, and the platform I am building provides full Hurl compatibility. I have been using Hurl for a few years now [2], and use it for my API testing, for orchestrating a bunch of HTTP APIs, and in general whenever I need to do anything with HTTP requests, I reach for Hurl. You can try without signup the basic execution feature with the free Open Editor [3], but for full functionality (retaining responses and cron triggers) you need a signed in account, even free. The Skybear.NET platform: 1. Has Hurl Compatibility, so take your local scripts and run them on the cloud as well. No changes needed. 2. Provides managed infrastructure for authoring, storing, and most importantly executing your Hurl scripts, that automatically scales to handle as many script runs as you need. 3. Generates detailed reports from your tests execution, automatically persisting requests and response bodies for introspection in the future, and with automatic insights coming up soon. 4. Supports multiple ways of triggering execution of your scripts, including periodic executions, and on-demand HTTP triggers enabling integration with your CICD pipelines. Most importantly, it eliminates excessive per-request/per-step/per-check charges, leading to substantial cost-savings for complex multi-step API tests covering complete user-journeys. I consider a "script project run" to be the main unit in my pricing, which includes execution of all the source files of the script project, which can be tens or hundreds of requests. I am starting to document some of the architecture of the platform as well [4], but in a nutshell, all your data is encrypted inside the application before stored on AWS (S3, DynamoDB, also encrypting at rest) [5], the control plane runs on Hetzner and AWS EC2, and the execution servers running your scripts run on Fly and soon on AWS EC2 (for some plans). Future plans depend a lot on feedback from users. I already have a long list of things I personally want to have, but as more users start using I would like to see user needs influencing the roadmap more. Some upcoming features: 1. Insights and metric graphs for historical tracking of your tests (per project, per file, per request URL). 2. Automatic generation of tests based on OpenAPI schemas, HAR files, etc. 3. Export API of all the data and reports for your own consumption. 4. OTEL traces generated per script run, exportable and sent to APM products. Thank you, and I hope you find it interesting too! Lambros Petrou 1. https://hurl.dev 2. https://ift.tt/bqFkjJm 3. https://ift.tt/37qFBPi 4. https://ift.tt/cXHIEUk... 5. https://ift.tt/dDCWGml https://www.skybear.net December 23, 2024 at 01:39AM

Show HN: Get e-signatures & pay per signed doc https://ift.tt/6PO9fFu

Show HN: Get e-signatures & pay per signed doc Woke up today with a 100-degree fever & found out Google is now our competitor. Last week, we started building signwith.co/ - a simple, pay-per-use e-signature tool for people who are struggling with complex e-sign tools. The plan was to build quietly, run a private beta, get 50 users in 15 days, and then do a launch. Easy peasy. But since Google dropped into the e-signature space - we needed to talk. So after 30 minutes of existential dread, a lot of “what are we even doing?” thoughts, and one strong dose of paracetamol we said, screw it. - let’s change gears. So now we're opening our beta, and here's the deal: • All the people who join will get free credits worth 10 signed docs • 12 months credit validity • No complexity • No hidden cost • No subscription commitment You can join the beta here - http://signwith.co That said, we see Google's entry in the signature space as validation. This event expanded the market with such massive awareness. Let me be clear: We’re not trying to be DocuSign, Google, or any other enterprise beast. We’re indie makers and building for: • The freelancers • The consultants • The indie and small business owners • and anyone who just needs a contract signed—fast, simple, no headaches. Here’s how SignWith works: • Upload your doc • Drop signature spots • Send it out and track • Pay per signed document That’s it. No subscriptions. No feature bloat. No crazy hidden charges and no complex pricing tiers. If you've read it so far, would love to see you on the other side. And hey, if you’ve got any feedback, suggestions, or just want to tell us what you need, reply here or drop me a DM. We’re all ears! Cheers! https://signwith.co/ December 20, 2024 at 05:03PM

Show HN: Rivet Actors – Durable Objects build with Rust, FoundationDB, Isolates https://ift.tt/pTq7i84

Show HN: Rivet Actors – Durable Objects build with Rust, FoundationDB, Isolates Hello! We posted a Show HN for Rivet last year for our container orchestration project ( https://ift.tt/EaCrtMe ). In that time, a lot has changed that I think HN will find interesting. Rivet is open-source actor infrastructure similar to Cloudflare's Durable Objects. Rivet itself already serves millions of MAU in production using our current container runtime – primarily for multiplayer games – and Rivet Actors are a new extension to support actor-like workloads. Rivet Actor's core primitives are RPC, state, and events. Actors are powered by Rust, V8 isolates (supports Deno), and FoundationDB. An architecture diagram is available here for [1]. If you're not familiar with FoundationDB, you're overdue to watch Dave Rosenthal's talk [3]. (I firmly believe it's by far the best permissively licensed database; if only it had a well maintained SQL layer.) Here's where Rivet's architecture gets fun – we don't rely on a traditional orchestrator like Kubernetes or Nomad for our runtime. Instead, our orchestrator is powered by an in-house actor-like workflow engine – similar to how FoundationDB is powered by their own actor library (Flow [4]) internally. It lets us reliably & efficiently build complex logic – like our orchestrator – that would normally be incredibly difficult to build correctly. For example, here's the logic that powers Rivet Actors themselves with complex mechanisms like retry upgrades, retry backoffs, and draining [2]. One of the reasons we built Rivet Actors is because we tried to replace most of our Redis-based realtime infrastructure with Durable Objects. The architecture allowed us to build realtime features much faster & efficiently, but the platform & APIs were needlessly rigid and difficult to use. Our goal is to build an actor-like platform that includes the bells and whistles required for developers to benefit from the actor model without the learning curve of tools like Erlang/OTP, Akka, or Orleans. Rivet Actors provides a few key benefits in flexibility over Durable Objects: - Open-source (Apache 2.0) – built to be self-hosted and deployed on-prem - Provides observability out of the box, no Logpush required - Rivet Actors support the Deno runtime, so NPM & JSR just works - @rivet-gg/actor [5] framework provides RPC, state, and events out of the box for faster bootstrapping; you can modify and deploy it yourself - Supports both V8 isolates & Docker-compatible containers so you can run any software you'd like, like Godot/Unity servers or video transcoding - Also supports TCP & UDP (we run games!) - Provides vanilla HTTP API for easy use with existing apps - Full control over regions There's plenty more that I don't have space to talk about. Give our docs a read if you'd like to learn more [6] or read about internal design decisions [7]. I'll be in the comments answering questions! Cheers, Nathan [1] https://ift.tt/Ap9ewSM [2] https://ift.tt/QSZdL4y... [3] https://www.youtube.com/watch?v=9g84y_60VGM [4] https://ift.tt/hRsUSC3 [5] https://ift.tt/nhkaA2u [6] https://rivet.gg/docs [7] https://ift.tt/6tMVbLp https://ift.tt/MJPKqkF December 20, 2024 at 10:06PM

Show HN: City Summit – buildings data visualization project https://ift.tt/JlH8x7K

Show HN: City Summit – buildings data visualization project https://ift.tt/4oCdSHM December 21, 2024 at 01:19PM

Show HN:Free Online Tool to Experience Microsoft's MarkItdown https://ift.tt/KWmYQBS

Show HN:Free Online Tool to Experience Microsoft's MarkItdown https://markitdown.pro December 21, 2024 at 10:43AM

Show HN: openai-realtime-embedded-SDK Build AI assistants on microcontrollers https://ift.tt/OabG5ie

Show HN: openai-realtime-embedded-SDK Build AI assistants on microcontrollers Hi HN! This is an SDK for ESP32s (microcontrollers) that runs against OpenAI's new WebRTC service [0] My hope is that people can easily add AI to lots of 'real' devices. Wearable devices, speakers around the house, toys etc... You don't have to write any code, just buy a device and set some env variables. If you have any feedback/questions I would love to hear! I hope this kicks off a generation of new interesting devices. If you aren't familiar with WebRTC it can do some magical things. Check out WebRTC for the Curious[1] and would love to talk about all the cool things that does also. [0] https://ift.tt/RgBzxso [1] https://ift.tt/z6KxvQZ https://ift.tt/pi4fhKw December 18, 2024 at 09:17PM

Show HN: Model Validation Using LLMs https://ift.tt/uzYM9WL

Show HN: Model Validation Using LLMs https://ift.tt/sYEVuUH December 21, 2024 at 12:31AM

Show HN: WebGPU Tech Demo https://ift.tt/1eBISVG

Show HN: WebGPU Tech Demo WebGPU tech demo running in modern browsers showcasing various rendering techniques like deferred rendering with 400+ dynamic lights, Hi-Z screen space reflections and cascaded shadow mapping. https://ift.tt/fxks1SO December 19, 2024 at 10:44PM

Show HN: CCState is a semantic, strict, and flexible state management library https://ift.tt/FUT5mCG

Show HN: CCState is a semantic, strict, and flexible state management library CCState is a semantic, strict, and flexible state management library suitable for medium to large single-page applications with complex state management needs. The name of CCState comes from three basic data types: computed, command, and state. https://ift.tt/70y6GFY December 19, 2024 at 03:44PM

Show HN: Musoq – Query Anything with SQL Syntax (Git, C#, CSV, Can DBC) https://ift.tt/lwymKaY

Show HN: Musoq – Query Anything with SQL Syntax (Git, C#, CSV, Can DBC) Hey, For those of you who don't know my little tool Musoq, I wanted to introduce it as a small tool that allows you to query with SQL-like syntax without any database. It allows you to query various things from niche ones like CAN DBC files, weird ones like C# code, interesting ones with Git querying to regular stuff like CSV, TSV and various others. I am quite a bit experimenting with various things so I'm hybridizing the engine with LLMs or doing other weird stuff that are more or less practical :-) I wanted also to share some recent developments in this little project as I hope it might be interesting to some of you. New Experimental Plugins: * Git Plugin (Beta) : I've been working on Git repository querying - managed to test it on the EF Core repo (16k commits) and it seems to work okay * Roslyn Plugin (Beta) : Added basic C# code analysis capabilities For the very first time: I've extended CROSS APPLY to use computed results as arguments! Now the operator can use values from the current row as inputs. Here's an example: SELECT f.DirectoryName, f.FileName FROM #os.directories('/some/path', false) d CROSS APPLY #os.files(d.FullName, true) f WHERE d.Name IN ('Folder1', 'Folder2') After another pack of fixes I'm finally able to query multiple git repositories AT ONCE! with ProjectsToAnalyze as ( select dir2.FullName as FullName from #os.directories('D:\repos', false) dir1 cross apply #os.directories(dir1.FullName, false) dir2 where dir2.Name = '.git' ) select c.Message, c.Author, c.CommittedWhen from ProjectsToAnalyze p cross apply #git.repository(p.FullName) r cross apply r.Commits c where c.AuthorEmail = 'my-email@email.ok' order by c.CommittedWhen desc Under the Hood: - Added a Buckets feature for memory management (currently just testing it with the Roslyn plugin) - Moved to .NET 8 - Added CROSS/OUTER APPLY operators - Made some improvements to error messages and runtime behavior New piping features: I've been experimenting with piping capabilities: * Image Analysis with LLMs : ./Musoq.exe image encode "image.jpg" | ./Musoq.exe run query "select s.Shop, s.ProductName, s.Price from ..." * Text Data Extraction : Get-Content "ticket.txt" | ./Musoq.exe run query "select t.TicketNumber, t.CustomerName ... from #stdin.text('Ollama', 'llama3.1') t" * Data Source Combination : { docker image ls; ./Musoq.exe separator; docker container ls } | ./Musoq.exe run query "..." I'm working on comprehensive documentation: I encourage you especially to look at section "Practical Examples and Applications" and "Data Sources" where you can look at all the tables the tool currently provides. < https://puchaczov.github.io/Musoq/ > Other Changes: - Made some improvements to OS and Archive data sources (OS can now query metadata like EXIF) - Added a few fields to CAN DBC plugin - Command outputs can now be used as inputs for queries I'm hoping to: - Improve stability and add more tests - Flesh out the documentation - Work on package distribution (Scoop, Ubuntu packages) - Share some examples of source code querying with Roslyn Ideas for later: - WHERE robust analysis and optimizations - DISTINCT operator implementation - PROTOBUF schema support - Performance improvements - Query parallelization - Recursive CTEs - Subqueries I'd really appreciate any thoughts or feedback! The documentation section where I write a short analysis of EF Core with git plugin: < https://puchaczov.github.io/Musoq/practical-examples-and-app... > https://ift.tt/2X3BrbG December 19, 2024 at 12:32AM

Show HN: Bodo – high-performance compute engine for Python data processing https://ift.tt/KPVjGiU

Show HN: Bodo – high-performance compute engine for Python data processing Hello HN, I’m excited to share Bodo, an open-source compute engine designed for large-scale data processing in native Python. Bodo is powered by an auto-parallelizing JIT compiler and an HPC backend, enabling it to generate highly optimized, parallel binaries (MPI) for Pandas and NumPy code—all without requiring any code rewrites. Our latest benchmark demonstrates 20x to 240x speedup over traditional distributed computing frameworks like Spark, Ray, and Dask (code and details in repo). The inspiration for Bodo came from my background in HPC, when I saw how extremely slow and hard to use Spark was (has gotten better over the years but still not great). Of course, a compiler has its own limitations (e.g. not all Python is compilable), but I think it’s leaps and bounds better. Let me know what you think. https://ift.tt/Qtxr6sj December 18, 2024 at 11:10PM

Show HN: I spent 4 years bootstrapping a financial planning tool to 30k MAUs https://ift.tt/yZ9fRHO

Show HN: I spent 4 years bootstrapping a financial planning tool to 30k MAUs Hey everyone! I'm back with an update on this post [0]. Last year, I quit my corporate job and went full-time on ProjectionLab, the long-term financial planning app I've been building for the past 4 years, which some of you may recognize. The decision to go all-in felt like a huge leap. But it was the right call, and it's been a good year. And without the HN community, it would not have happened. As I mentioned last time [0], the feedback on my original Show HN is THE reason I'm still here working on this. I'm really grateful for that. And I hope the way I’ve grown PL -- staying bootstrapped and focused on users -- resonates with the early supporters who helped to shape it. For now I'm still the only engineer, burning the candle at both ends, but luckily I'm not feeling burnt out myself! It's been a fun and memorable year: - 6,139 commits, 221,484 insertions, 116,255 deletions - Shared my story on the ChooseFI podcast [1] (one of the original sources of inspiration for this project) - Started building a team (2 team members for customer success, 1 leading growth & marketing) - Doubled our customer base - Took no external funding, keeping our interests as aligned with users as possible Okay, but what did I actually do since last time? [2] Here's a quick cross-section: - Compare mode upgrades to explore what-if scenarios overlaid on the same chart with visual deltas/diffs - Launched ProjectionLab for Employers [3]: offer PL as a benefit, or get your employer to pick up the tab - Major tech stack migrations: Vue 2 -> Vue 3, Vue CLI -> Vite, Vuetify 2 -> Vuetify 3, Vuex -> Pinia, Jest -> Vitest, Firebase Namespaced API -> Modular API, Vike + SSG for marketing site - Advanced visualization features (1-click-plot any metric, interactive event icons in charts, etc) - Improved tax estimation & tax analytics - Simultaneous editing on multiple devices - MFA support - Rebuilt the help center, added more educational content and YouTube tutorial videos - Made it possible to book a 1-on-1 session for educational/training purposes - Converted ~65% of the codebase from JavaScript to TypeScript - And more! [2] I never saw myself as an entrepreneur/founder type. But apparently I've now spent 4 years turning a side project into a real business. I couldn't have done it without the initial support from this community, and I'd love to hear what you think of the updates and where you'd like to see things go from here. --Kyle [0] https://ift.tt/7OYbqw8 [1] https://ift.tt/OvtYCeD... [2] https://ift.tt/nqF9KSL [3] https://ift.tt/BnOXWy6 https://ift.tt/W6uInjf December 18, 2024 at 08:27PM

Show HN: Adventures in OCR https://ift.tt/98o0sur

Show HN: Adventures in OCR Hello HN! In a recent "Ask HN: What are you working on?" thread, I mentioned I was working on OCRing a large book: https://ift.tt/qDjsG7A The post generated some interest so I thought I would keep HN posted. The book is Saint-Simon’s Memoirs -- an invaluable historical account of the French court under Louis XIV, full of wit, sharp observations, and of incredible literary value. I'm OCRing the edition of reference made between 1879-1930, that contains a lot of comments and footnotes: 45 volumes, ~27,000 pages. Here's a link to a blog post that describes the techniques used so far (the project is still ongoing): https://ift.tt/ExGTpSe But you may also directly access the result here: https://ift.tt/Dn2Fl0S This web app (not optimized for mobile, sorry) solves a tricky problem of preloading images efficiently. In short: preloading the next image isn't enough, since browsers will repaint if an image is moved, or scaled. Or browsers won't paint at all if visibility is hidden or opacity is zero, and will paint only when those values change. On an average, slow machine, this takes visible time. But if an image is simply behind another element, it will be painted, and the removal of the covering element or changing the z-index will not trigger a repaint. (Preloading is important because it lets one review results fast; if one has to wait 150-200 ms between images it's simply discouraging). Would love to hear feedback; happy to answer any question! https://ift.tt/ExGTpSe December 17, 2024 at 10:30PM

Show HN: I built an open-source data pipeline tool in Go https://ift.tt/7DtL1cU

Show HN: I built an open-source data pipeline tool in Go Every data pipeline job I had to tackle required quite a few components to set up: - One tool to ingest data - Another one to transform it - If you wanted to run Python, set up an orchestrator - If you need to check the data, a data quality tool Let alone this being hard to set up and taking time, it is also pretty high-maintenance. I had to do a lot of infra work, and while this being billable hours for me I didn’t enjoy the work at all. For some parts of it, there were nice solutions like dbt, but in the end for an end-to-end workflow, it didn’t work. That’s why I decided to build an end-to-end solution that could take care of data ingestion, transformation, and Python stuff. Initially, it was just for our own usage, but in the end, we thought this could be a useful tool for everyone. In its core, Bruin is a data framework that consists of a CLI application written in Golang, and a VS Code extension that supports it with a local UI. Bruin supports quite a few stuff: - Data ingestion using ingestr ( https://ift.tt/UH8JowZ ) - Data transformation in SQL & Python, similar to dbt - Python env management using uv - Built-in data quality checks - Secrets management - Query validation & SQL parsing - Built-in templates for common scenarios, e.g. Shopify, Notion, Gorgias, BigQuery, etc This means that you can write end-to-end pipelines within the same framework and get it running with a single command. You can run it on your own computer, on GitHub Actions, or in an EC2 instance somewhere. Using the templates, you can also have ready-to-go pipelines with modeled data for your data warehouse in seconds. It includes an open-source VS Code extension as well, which allows working with the data pipelines locally, in a more visual way. The resulting changes are all in code, which means everything is version-controlled regardless, it just adds a nice layer. Bruin can run SQL, Python, and data ingestion workflows, as well as quality checks. For Python stuff, we use the awesome (and it really is awesome!) uv under the hood, install dependencies in an isolated environment, and install and manage the Python versions locally, all in a cross-platform way. Then in order to manage data uploads to the data warehouse, it uses dlt under the hood to upload the data to the destination. It also uses Arrow’s memory-mapped files to easily access the data between the processes before uploading them to the destination. We went with Golang because of its speed and strong concurrency primitives, but more importantly, I knew Go better than the other languages available to me and I enjoy writing Go, so there’s also that. We had a small pool of beta testers for quite some time and I am really excited to launch Bruin CLI to the rest of the world and get feedback from you all. I know it is not often to build data tooling in Go but I believe we found ourselves in a nice spot in terms of features, speed, and stability. https://ift.tt/fvZGn2u I’d love to hear your feedback and learn more about how we can make data pipelines easier and better to work with, looking forward to your thoughts! Best, Burak https://ift.tt/fvZGn2u December 17, 2024 at 10:10PM

Show HN: Graph-Based Editor for LLM Workflows https://ift.tt/wbWd5Yh

Show HN: Graph-Based Editor for LLM Workflows Hey HN, We’re excited to share PySpur, an open-source tool that provides a graph-based interface for building, debugging, and evaluating LLM workflows. Why we built this: Before this, we built several LLM-powered applications that collectively served thousands of users. The biggest challenge we faced was ensuring reliability: making sure the workflows were robust enough to handle edge cases and deliver consistent results. In practice, achieving this reliability meant repeatedly: 1. Breaking down complex goals into simpler steps: Composing prompts, tool calls, parsing steps, and branching logic. 2. Debugging failures: Identifying which part of the workflow broke and why. 3. Measuring performance: Assessing changes against real metrics to confirm actual improvement. We tried some existing observability tools or agent frameworks and they fell short on at least one of these three dimensions. We wanted something that allowed us to iterate quickly and stay focused on improvement rather than wrestling with multiple disconnected tools or code scripts. We eventually arrived at three principles upon which we built PySpur : 1. Graph-based interface: We can lay out an LLM workflow as a node graph. A node can be an LLM call, a function call, a parsing step, or any logic component. The visual structure provides an instant overview, making complex workflows more intuitive. 2. Integrated debugging: When something fails, we can pinpoint the problematic node, tweak it, and re-run it on some test cases right in the UI. 3. Evaluate at the node level: We can assess how node changes affect performance downstream. We hope it's useful for other LLM developers out there, enjoy! https://ift.tt/sMp1BiZ December 16, 2024 at 11:50PM

Show HN: Autonomous AI agents that monitor the stock market for you https://ift.tt/biGIEMj

Show HN: Autonomous AI agents that monitor the stock market for you We created autonomous AI Agents that monitor the stock market for you while you go about your day. How it works: Tell our AI Assistant what you want to monitor, and it creates a project for our team of autonomous AI Agents. You'll get notifications (email + app) when significant events matching your criteria are detected. For short-term projects, you'll be notified when your analysis is ready. Behind the scenes: When you give the AI Assistant a request to monitor an entity (like a stock or group of stocks), an AI Project Manager plans the project and breaks the project down into manageable tasks. These tasks run asynchronously - some recurring (hourly/daily/weekly/monthly/quarterly/yearly), others one-time. Example prompts you can try: Long-term monitoring: - "Monitor Apple stock and notify me of any important events and red flags" - "Monitor Apple, Google, Microsoft, and Meta stock. Notify me if any of them start trending toward being undervalued" Short-term analysis: - "Create a project to analyze the last 30 earnings calls for Tesla, spot trends, and how the business has evolved over time" You can track the progress of all tasks as the AI Agents work in the background. Try it here: https://ift.tt/kujZIBv This is still an early version - we're actively improving it based on feedback. Would love to hear what you think and what features you'd want to see next! Previously shared our AI-powered Stock Market Research Analyst: https://ift.tt/1ZK2oCi https://ift.tt/FhkoYE7 December 16, 2024 at 11:53PM