Show HN: GuideLab – in-app user guides for their entire journey https://ift.tt/WwmEbkU

Show HN: GuideLab – in-app user guides for their entire journey Hi HN, I’m James and I’m excited to share GuideLab, on-demand in-app guides to reduce support load and make your users happier. After a decade of working on products with small (20k) and large (millions) user bases, one thing remained clear - level 1 support takes up a lot of time. From universal usability (’how do I reset my password?’, ’how do I invite team members?’) to product specific problems, the answer is sometimes in a chat bot or knowledge base, but it’s cumbersome for the user and often gets lost in translation. Using GuideLab, you create in-app guides through a UI ("no code") which can then be shared with your users via a link special link over any platform: email, Zendesk, Intercom, in a KB, social media etc. As soon as a user clicks the link, they’re taken to your app and instantly see the guide. There’s also our search widget that you can embed directly in your web app. A 'Help Guides' tab appears for the user, where they can search and view any guide you've created. In that way GuideLab is fundamentally different to other guiding software like AppCues or userpilot. They focus on opting users into guides based on cohorts/attributes whereas GuideLab lets users view guides when they need them most. There’s a quick (<1m) video on the homepage ( https://guidelab.io ) walking you through how GuideLab works. If you have any other questions, or if there’s anything you’d love to see in this space, please share. https://guidelab.io February 11, 2022 at 03:10AM

Show HN: The BLAKE3 hash function running on a 6502 microprocessor https://ift.tt/oIvn2Uc

Show HN: The BLAKE3 hash function running on a 6502 microprocessor https://ift.tt/7soqwz1 February 11, 2022 at 11:57AM

Show HN: 50x50.space a public board to doodle together https://ift.tt/vpf3zYQ

Show HN: 50x50.space a public board to doodle together https://50x50.space February 11, 2022 at 10:45AM

Show HN: Hardle – Hard Wordle where the color of the hints is not known https://ift.tt/enEDJzH

Show HN: Hardle – Hard Wordle where the color of the hints is not known https://ift.tt/WsxjGEI February 11, 2022 at 02:55AM

Show HN: Lessons learned from my 10 year open source project https://ift.tt/7uGJV5O

Show HN: Lessons learned from my 10 year open source project I've been developing SpiderFoot (an OSINT/recon tool) for 10 years now, so wanted to share my story and try to distill some lessons learned in the hope they might be helpful to others here who might be considering writing/open-sourcing their own tools. Here's the post: https://ift.tt/VteTSIy And the repo if you want to check it out: https://ift.tt/pfMPdcw -- TL;DR version of lessons from the post.. Lesson 1: Writing open source software can be very rewarding in ways you can’t predict Lesson 2: Be in it for the long haul Lesson 3: Ship it and ship regularly Lesson 4: Have broad, open-ended goals Lesson 5: If you care enough, you’ll find the time Lesson 6: No one cares about your unit test coverage Lesson 7: There’s no shame in marketing Lesson 8: Clear it with your employer Lesson 9: Foster community Lesson 10: Keep it enjoyable -- I hope you find it useful and inspires some of you to get your project out there! Feel free to ask me any questions here and I'll do my best to answer. February 11, 2022 at 02:16AM

Show HN: Training synthetic models on highly complex datasets https://ift.tt/yj8U2QR

Show HN: Training synthetic models on highly complex datasets https://ift.tt/s8ti1Eg February 11, 2022 at 01:48AM

Show HN: A Schemaless Data Store Within Your SQL Database https://ift.tt/mcD25Oe

Show HN: A Schemaless Data Store Within Your SQL Database Hi HN, we're Eric and Dean, creators of SchemafreeSQL. Its roots go back to an on-line Web App Development Environment we developed back in 1999. It was comprised of an IDE, Web Server, Object Store, Virtual File System, Template System, and polyglot (Java, JavaScript, and Python). Of course, we named it “.OS”. Then we ended up dropping it. But that's a story for another time. It was the ease of use of the Object Store from .OS that we really missed, which brings us back to SchemafreeSQL. It provides an enhanced API to your SQL Database which allows it to function as a Schemaless Objectstore. Yes, "Schemaless Objectstore" might be an oxymoron if you consider that objects have strict "schemas". So what are we talking about here? It started with a simple goal. We wanted to store data just as simply as one could throw a JSON document into a doc store, but while maintaining the power of the data's relations and references in an object sense. What we ended up with was a JSON over HTTP API (for ubiquitous access from any language), that maps any JSON structure into an optimized, static set of indexed tables in any SQL database (MySQL being our first port). Using it, we can immediately store any data we want, without having to create tables and indexes and optimize them. Inserting data is as easy as sending a JSON doc to a doc store, but in SFSQL all nested relations inherent within that document are stored as objects and primitives. And, with a little extra JSON syntax we can use references and eliminate duplication of data (e.g. "#ref": "oid-goes-here"), all from within the same source JSON doc. There is also no added speed penalty for referencing an object. In fact, all parent nodes in the JSON source data are stored as objects. So any object can be referenced from anywhere, allowing for complex relations (e.g. any-to-any), enabling rapid prototyping of data structures (no tables to create), and enabling unique on-the-fly relations if need be. Queries are issued using JOIN-free SQL query syntax (e.g. SELECT COUNT(*) WHERE $s:person.address.state='NY') that eliminates the verbosity of the standard SQL JOIN, yet still maintains access to the primitive and aggregate functions of the underlying SQL database (e.g. FORMAT(), COUNT(), etc.) which simply get passed through. What it's not? It's not a database on it's own and it's not a horizontally scalable big data store. Although, since it can extend practically any SQL database, it's ability to scale is in large part tied to the scaling ability of the chosen SQL database that it's extending. It's also not an ORM as there is no strict mapping of objects in code to objects in the datastore. And yes, there were trade offs in it's design. One design choice was that every primitive be indexed, which results in better performance than against a straight SQL table without the proper indexes, though slower than a straight SQL table with a composite index tailored to that query. But, the ability to JOIN to an existing SQL table within a SFSQL query is on the roadmap which will allow you have the best of both worlds (custom tables w/custom indexes referenced from within a SFSQL query). As well, there is a situation one encounters in indexing choices (but that you won't encounter with SFSQL) that we like to call the "Index Permutation Limitation". Simply put, there is a real limit to the number of composite indexes that you can create for any table/collection. This is especially a problem when - for instance - you want to give end users the ability to query across any of the possible attributes across the myriad product types that a big online store may carry. We get into detail on this point within our FAQ. So what it is? It's an extension to SQL databases that makes storing and querying and modeling and just generally using a datastore... easier. We're hoping it will stir up some interesting use-cases. Thanks in advance for the feedback! https://ift.tt/XQZ9G13 February 11, 2022 at 01:27AM