Ready for some wordplay? Sharpen your skills with Slate’s puzzle for April 26, 2024.

Slate Crossword: Shooting Stars’ Org.? (Three Letters)

Welcome to Slate’s weekly news quiz. It’s Friday, which means it’s time to test your knowledge of the week’s news events. Your host, Ray Hamel, has concocted questions on news topics ranging from politics to business, from culture to sports to science.

Slate News Quiz: Trump trial, bird flu, campus protests.

Photo illustration by Slate. Images by carles miro/iStock/Getty Images Plus and Getty Images Plus.

Help! I Agreed to Be My Friend’s Maid of Honor, but Her Relationship Is a Giant Red Flag.

Photo illustration by Slate. Photo by Getty Images Plus.

Parenting advice: My kid has a very strange idea about how she’ll become “talented.”

Photo illustration by Slate. Photos by Alex Wong/Getty Images and Erin Schaff/Pool/Getty Images.

Supreme Court immunity arguments: The court just showed how and why it will let Donald Trump get away with it.

The threat of a “prohibition” in the United States, and that ByteDance could lose out on a lot of money, is merely the law’s way to force a sale of the propaganda dance app and put it in the hands of a patriotic American company, such as McDonald’s or Slate.

Will TikTok be banned in the U.S.? Explaining why Joe Biden signed the China-related law.

Test your wits on the Slate Quiz for April 25, 2024.

Trivia quiz: Slate’s daily game of questions about science.

Ready for some wordplay? Sharpen your skills with Slate’s puzzle for April 25, 2024.

Slate Crossword: Namesake of a Razor You Can’t Shave With (Five Letters)

When you&#x27;ve lost Justice Barrett on an abortion case ...

The Lawyer Defending Idaho’s Abortion Ban Irritated the One Justice He Needed on His Side

Photo illustration by Slate. Photo by MoreISO/Getty Images Plus and Jordan Pettitt/PA Images via Getty Images.

Five Escaped Horses Rampaged Through Central London for Two Hours This Morning, By the Way

OUR MISSION\nSlate has big ambitions: We were born out of our Founders’ own experiences to solve the problems we all faced with social media

Slate

Building an awesome editor for your React-based web application is by no means easy. But with things get much easier. Even with the help of Slate, building a full-featured editor is way more work than we can cover in one blog post, so this post will give you the big picture and subsequent posts will dive into the dirty details. SlateJS Note: this post is based on a recent talk at the JavaScript NYC meetup. You can watch the video here: SlateJS We're building , a new, fast, and highly collaborative alternative to issue trackers like Jira, Trello, and Clubhouse. We're big believers in remote work, and in particular working asynchronously so that team members get large, uninterrupted blocks of time to get work done. A key to supporting this type of work is having a really great editor so that teams are inspired to collaborate together on issues and ensure alignment. And we think we've got the best editor around: Kitemaker Markdown shortcuts, code blocks with syntax highlighting, images, embedding designs from , math expressions with LaTex, diagrams with , and, of course, emojis ♥️. All done entirely with Slate. Figma MermaidJS So why did we choose to go with Slate in the first place? It's definitely not the only editor framework out there. For us, the things that pushed us towards Slate were: It's un-opinionated about how your document is structured, and that gave us the flexibility we needed It doesn't force any built-in toolbars or any other visuals upon you It's built with React in mind and that makes a huge difference when rendering complex documents It lays the foundation for collaborative editing which is something we believe is important for Kitemaker We really like the philosophy behind it It has a thriving community, particularly on Slack How Slate represents documents One of the best parts of Slate is how it holds very few opinions about how documents are structured. It has only a few concepts: Editor - the top level container of your document Block level elements - the domain-specific "chunks" that make up your documents, like paragraphs, code blocks and lists. These are the things you can draw horizontal lines between in your document Inline elements - special elements that flow inline with the text of your document, like links Text nodes - these contain the actual text in the document Marks - annotations placed on the text, such as marking text as bold or italic Astute readers will notice that this is structured very similar to the DOM, and text, block and inlines in Slate behave very much like their counterparts in the DOM. Here's an annotated screenshot of a Slate editor to explain these concepts visually: Slate uses a very simple JSON format for representing documents, and the document above would look like this in Slate's representation: [
 { : , : [
 { : },
 { : , : , : [
 { : }
 ]
 },
 { : }
 ]
 },
 { : , : [
 { : },
 { : , : },
 { : },
 { : , : },
 { : }
 ]
 }
] "type" "paragraph" "children" "text" "Text with a link " "type" "link" "url" "https://kitemaker.co" "children" "text" "https://kitemaker.co" "text" " here" "type" "paragraph" "children" "text" "Text with " "text" "bold" "bold" true "text" " and " "text" "italic" "italic" true "text" " here" As we said before, Slate is really un-opinionated about how documents are structured. In the JSON blob above, the only thing Slate cares about is that it gets an array of block elements with a property and that those children are either other block elements, or a mixture of text nodes and inline elements. That's it. Slate doesn't care about the , or properties and it doesn't care about how these various nodes will be rendered. This makes it really flexible and powerful to work with. children type url bold Hello world editor Enough background. Let's look at some code! Let's see what a simple editor component looks like using Slate: { editor = useMemo( withReact(createEditor()), []); [value, setValue] = React.useState<Node[]>([
 { : [{ : }],
 },
 ]); ( <Editable /> );
} ( ) function MyEditor const => () const children text 'Testing' return setValue(v)}> < = = = => Slate editor {editor} value {value} onChange {(v) </ > Slate And that's it. That's an entire working component with Slate! We use to make ourselves an editor (don't worry about for now - that's a plugin, which we'll discuss below) createEditor() withReact() We make a simple array of nodes to store the document (just like we looked at above) We instantiate a component which serves as a context provider, providing the editor we created above to all of the components below it. This is really cool because you can, for example, add toolbars and other components below the component that can grab the editor and manipulate the document with it. We also wire up the and properties, similar to any input in React <Slate> <Slate> value onChange We add an component which is the actual editor the user interacts with on the screen <Editable> Boring. How do we extend things? So while that previous example was trivial to write, we still only have an editor that works about as well as . Not very exciting. <TextArea> Luckily Slate provides mechanisms for making things a whole lot more interesting: plugins allow us to override the core behavior of the editor. They're not concerned with rendering, just with overriding what happens when (for example) text is inserted, or an image is dropped Plugins: allow us to handle things like key presses, so we can add hotkeys or allow pressing 'tab' to indent a bulleted list Event handlers: with Slate we can specify exactly how each and every node in our document should be rendered using React Custom rendering with React: Let's take a quick look at each of these. Plugins Plugins are a deceptively simple, powerful concept in Slate. Plugins generally look something like this: { { insertText, insertData, normalizeNode, isVoid, isInline } = editor; editor.insertText = { insertText(text);
 }; editor.insertData = { insertData(data);
 }; editor.normalizeNode = { normalizeNode(entry);
 }; editor.isVoid = { (element.type === ) { ;
 } isVoid(element);
 }; editor.isInline = { (element.type === ) { ;
 } isInline(element);
 }; editor;
 } export ( ) function withMyPlugin editor: ReactEditor const // called whenever text is inserted into the document (e.g. when // the user types something) ( ) => text // do something interesting! // called when the users pastes or drags things into the editor ( ) => data // do something interesting! // we'll dedicate a whole post to this one, but the gist is that it's used // to enforce your own custom schema to the document JSON ( ) => entry // do something interesting! // tells slate that certain nodes don't have any text content (they're _void_) // super handy for stuff like images and diagrams ( ) => element if 'image' return true return // tells slate that certain nodes are inline and should flow with text, like // the link in our example above ( ) => element if 'link' return true return return By convention, their names start with . They take a Slate editor, override whatever functions they need to override and return the modified editor back. Very often, they handle a few cases in some of these functions and fall back to the default behavior for the rest. about 80% of adding functionality to a Slate editor is doing string matching in these plugin functions and then manipulate the document using Slate's rich API. with Spoiler alert: There are more functions you can override than the ones shown above, but these are the most common by far. You can read all about plugins in . Slate's documentation One of the most powerful parts of Slate plugins is that they can be composed together. Each plugin can look for the things it cares about and pass everything else along unmodified. Then you can compose multiple plugins together and get an even more powerful editor: { editor = useMemo( withReact(withDragAndDrop(withMarkdownShortcuts(withEmojis(withReact(createEditor())))), []);
 ...
} ( ) function MyEditor const => () Event handlers Like many React input components, the component has a bunch of events to which you can listen. We don't have time to go through them all here, but we'll mention the one we use most often: <Editable> onKeyDown() By handling this event, we can do all sorts of powerful things in our editor, like adding hotkeys for example: <Editable
 onKeyDown={(e) => { (e.metaKey && e.key === ) {
 e.preventDefault();
 Editor.addMark(editor, , );
 }
 }}
 ...
/> // let's make the current text bold if the user holds command and hits "b" if 'b' 'bold' true We use key down events in Kitemaker: everywhere Nesting and un-nesting lists when tab is pressed Breaking out of lists and code blocks when enter (or in some cases backspace) is pressed Splitting blocks (e.g. headlines) when enter is pressed in the middle of a block And many many more Custom rendering with React Slate has no opinions on how your blocks and inlines should look on the screen. By default, it just shoves all blocks into plain elements and all inlines into plain elements, but that's pretty dull. <div> To override Slate's default behavior, all we need to do is pass a function into the component's property: <Editable> renderElement <Editable
 renderElement={({ element, attributes, children }) => { (element.type) { : ; : ; : ;
 }
 }}
/> switch case 'code' return {children} < { }> pre ...attributes </ > pre case 'link' return {children} < = { }> a href {element.url} ...attributes </ > a default return {children} < { }> div ...attributes </ > div All this code is doing is looking for the property on a node and picking a different rendering path based on that. Remember, as we said before, Slate doesn't care about these properties, only do. So while the convention is to use to denote the type of a node, nothing is forcing you to do so. You can also add all sorts of other properties to your components that help with the rendering (like the url property we saw on links above). type we type The things returned from just need to be React components. What they look like and their complexity is entirely up to you. Here we're returning a simple element to denote a code block, but nothing is stopping us from returning a full blown component that supports syntax highlighting (like we do in Kitemaker). renderElement <pre> <Code> There's only one important thing to remember when implementing your own rendering - always spread the parameter as properties on the topmost component you're returning. If you don't, Slate won't be able to do its own internal bookkeeping and things will go very badly for you. attributes This has been a super quick introduction to custom rendering, so don't worry if you don't fully grasp it yet. What's tricky in Slate? You've now seen some of the basics of Slate, so you're ready to start experimenting. We thought we'd warn you a little about some of the pitfalls and tricky parts of working with Slate so you'll see them coming and not get discouraged: copying and pasting on the web is a mess. We'll dedicate a whole post to how we handle this in Kitemaker. Short version is that to test our own "paste logic", we have made a somewhat complex document in a bunch of popular web editors Google docs, Notion, Dropbox Paper, Quip, etc. Copying and pasting: by default, Slate doesn't support undo/redo. It does however come with a plugin called that provides this functionality. However, we've found that this doesn't provide the exact user experience we're looking for and so we've had to extend it ourselves History: useHistory() dealing with things that pop up and need to be positioned correctly (like what you see in the Kitemaker editor above when "/" is typed to insert a block or "@" is typed to mention a user) can be pretty tricky Hovers/floating menus: Kitemaker is a product with a ton of hotkeys for everything (we want our users to be able to use it without lifting their hands off the keys) but sometimes there have been some challenges with the key handling in Slate "fighting" with our hotkeys Key handling: Slate's API is quite extensive and we haven't even begun to touch on it in this post. There are many, many functions for manipulating the document (adding nodes, removing nodes, splitting nodes, wrapping nodes, adding text, deleting words, etc.) and it's not always totally obvious which API to use in which situation Big API surface: we've had complaints from users using MBPs and also things like pen inputs for writing Japanese. There's a to fix some strange behaviors so hopefully it'll be fixed soon 🤞 Some wonkiness with input methods like the Macbook Pro touch bar: PR open We'll cover some of these advanced topics in our subsequent posts. And a brief word of warning While we've been very happy with Slate so far, there are a few warnings that any team embarking on building their own editor should be aware of: Like any open source project, progress on Slate comes in waves. While there was a huge rewrite last year and things moved really quickly, progress has now slowed down considerably. There are lots of open issues and open PRs. We hope we can do our share to improve this going forward, but the community could use more support After the rewrite last year, the documentation hasn't quite gotten back to the standard it was before the rewrite. There's a fair amount of stubbed-out documentation that lacks the details required by developers who are just getting started with the project. We've submitted some changes to improve this, but more work is needed Slate is not properly supported on Android. Fortunately, there was a to fix this. Awesome! 🤙 Kickstarter project funded More to come! We hope this served as a nice high level introduction to Slate for you and gave you some of the information you need about whether or not to give Slate a try. There is way way way too much material to cover in a single post, but there will be a number of posts that follow that dig into some of the more complex topics. Thanks for reading! Did you find this article useful? If you want to see more material like this follow and on Twitter. @ksimons @KitemakerHQ Kevin Simons is the CTO of Kitemaker, the super-fast issue tracker that gives distributed teams superpowers Previously published at https://blog.kitemaker.co/building-a-rich-text-editor-in-react-with-slatejs

How We Built A Rich Text Editor in React with SlateJS

Last week . Google has promoted Chromebook devices as productivity machines for years but up until announcing at the 2018 Android Developer Summit this was not the case for Android developers like myself. When I started coding in 2014 I looked forward to being able to write and use the same apps across my phone and computer via a powerful and portable Chromebook. The Pixel Slate is that Chrome Os device. Pixel Slate started shipping to customers support for Android Studio Pixel Slate Is Great For Android and Web Developers With the balance of software flexibility, power, and design, if I knew I was solely developing for Android and backend moving forward I would make the leap from my current Macbook Pro to the . Pixel Slate What’s Enticing About Pixel Slate For Developers via native Linux support. Run almost any development software are becoming more common with high end Chromebooks such as the , , and leading the charge. Although Pixel Slate is not in the same league as a fully decked out Macbook Pro, the Slate seems to have plenty of fire power for compiling and running apps. As context, according to the processor benchmark scores from below, Pixel Slate has almost the power of my 2009 13’’ Macbook Pro which I’m still developing Android apps without issue. Powerful processors enough Pixel Slate Pixelbook Acer Chromebook Spin 13 Geekbench 4 3x 10 year old Processor Scores Geekbench 4 potentially compared to using an emulator. Test Android apps directly on the device without using a physical device. Test real-world usage with touchscreen without taking up a whole table. No one should want to be the shmuck in a cafe using an entire table with a laptop stand and bluetooth keyboard. Elevating the screen is great because it puts less strain on the neck. how staring down puts additional weight on the neck and spine which is not healthy. With the Pixel Slate tablet form factor elevating only the screen uses half the space as a traditional laptop. With a laptop there are 2 keyboards worth of space, the keyboard attached to the laptop and a separate keyboard for typing. Brydge, a popular keyboard for iPads, makes a which is better than the because it offers a firm hinge when connected. Save your neck The Atlantic highlights Pixel Slate keyboard Google keyboard The Atlantic, What Texting Does to the Spine by OLGA KHAZAN For All Users that is not possible with web apps. More functionality with Android apps Naming a few features: and : View inboxes for all accounts at once. Gmail Google Calendar : No standalone web app. Google Tasks : Messaging. Instagram : Listen to converted text to audio content. Pocket , , : Offline content. Pocket Casts YouTube Netflix with the by Google seems like a great solution for those who love to take hand written notes on the go. Note taking pressure sensitive pen for unlocking the device and potentially passwords and payments. Fingerprint sensor with a . Charge on the go USB-C battery pack , thanks again to USB-C. Fast charge other devices Wirecutter: The Best USB-C Battery Packs and Power Banks Why I’m Not Buying One Max Storage Option is Low Considering similar device’s specs and the fact that the fully spec’d Pixel Slate is I’d hope to have 500 GB. Last year’s Pixelbook offers 500 GBs and the new iPad pro offer a 1 TB option. This is not a deal breaker. $1,599 I could still make the max 250 GB Pixel Slate work. With my estimate based on current phone and Macbook usage I’d use 146 GB leaving me at 58% capacity. A lack of storage can cause performance issues so to start off at 58% capacity is workable, but not ideal if you’re aiming to the device for years to come. according to CNet Minimum estimated required storage needed for computer. ’Hacky’ Solutions for iOS Development I view purchasing tech as a long term investment. As I said above, I’m still using my 2009 Macbook Pro with many components updated. Currently I’m writing Android apps which would be great with the Pixel Slate. However, if there is any possibility of getting into iOS development in the future there is no way to do so cleanly on a Chrome Os device. . This is a deal breaker. Xcode is restricted to macOs only The options for iOS development on a Chromebook are: Running macOs off a virtual machine thus breaking Apple’s End User License Agreement. Using a cloud solution such as which even if it doesn’t have performance issues, if you use a cross platform solution such as or you’ll have to do that all in the cloud environment to run both Android and iOS at the same time. macInCloud Flutter ReactNative Therefore I must bend the knee to Apple. prettywhiskey.com Potential iOS Development Solutions (not likely in the short term) Either Google’s Flutter or Facebook’s ReactNative creates a process to submit iOS apps without requiring Xcode on your local machine. King Cook opens up Xcode for non macOs devices. I’m Adam Hurwitz — hit the clapping hands icon and check out the rest of my writing if you enjoyed the above. Thanks for reading!

Pixel Slate is (Almost) Great For Developers

How To Write Integration Tests in Go Apps

A Leap Into the Future: 0G's Newton Testnet 0G Labs, a newcomer to the fast-growing arenas of blockchain and artificial intelligence, has launched the Newton Testnet. This testnet is the predecessor of an ultra-scalable Modular AI Blockchain known as 0G or ZeroGravity. The testnet is a playground for node operators, developers, and a dedicated community. All of these people have been allowed to dip their toes and contribute crucial information before the big mainnet launch, which is slated for the third quarter of 2024. This new breakthrough is a tidal wave aimed at overcoming the scalability and data throughput challenges that have hampered blockchain-AI integration. 0G's modular design philosophy seeks to reduce blockchain's restrictions, which have long limited its utility as a vehicle for AI's complex data and execution requirements. To avoid outdated consensus mechanisms and decrease congestion caused by disconnected use cases, 0G's engineers purposefully developed a lean network. AI On-Chain Demand: Challenges In the digital era, we are drawn to (AI). It is as trustworthy and fair as we make it. Thus, it is an excellent venue for neural network training and deployment. Huge firms see AI as a foundation that will alter their industry, not a fad. Intellectual property and privacy concerns, biased generative AI models, and a lack of legal order all inhibit progress. artificial intelligence It also advocates for fair remuneration for all parties involved in the AI value chain, as well as AI data that is easily trackable. To get the most out of both autonomy and human interaction, avoid deep fakes and provide a well-balanced physical control system that validates AI outputs. AI that operates on the blockchain is not conceivable due to system problems. 0G comes first on the blockchain. This option can manage over 50 Gbps of data, but Ethereum's alternatives can only handle 1.5 Mbps. Because it may expand indefinitely, 0G's nature allows it to influence how distributed ledger technology is employed. 0G Labs completed a massive $5 million pre-seed financing round to launch a minimally viable product. This comment followed the company's testnet announcement. With the help of top Web3 investors like Bankless and Polygon, this fundraising round demonstrates the market's unwavering faith in 0G's vision. The fact that 0G is building a blockchain and enabling on-chain AI applications in the Web3 ecosystem is proof of this. About 0G At its heart, 0G, or ZeroGravity, is more than a blockchain; it serves as a conduit for the high-stakes dance between AI and blockchain. 0G reaches an incredible data throughput of 50 GB/second because to its innovative design that combines data storage and data broadcasting. This is more than a jump; it is a vault over present benchmarks, assuring that scalable Layer 2 solutions are viable for the first time, and modular AI are tactile realities inside the Web3 domain. With a cost structure that is a fraction of its rivals, 0G is not only participating in the blockchain revolution but also leading the charge. Don’t forget to like and share the story! This author is an independent contributor publishing via our . HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR. Vested Interest Disclosure: business blogging program

ZeroGravity Takes Off: 0G's Newton Testnet Pioneers the Future of AI-Blockchain Fusion

HackerNoon editorial team has launched to celebrate their achievements and share their struggles. We need more women in technology, and by sharing stories, we can encourage many girls to follow their dreams. ! this interview series with women in tech Share your story today Tell us about yourself! Thank you for having me! As a leading Product Manager at InDrive, a global ride-hailing service, I’m passionate about making transportation more accessible and efficient. With experience in the tech industry, surpassing more than five years, I’ve spearheaded product launches across 17 countries, impacting the lives of millions of users. Recently, I was honored to serve as a jury member for a 2023 Globee Women in Business Awards and the AI for Humanity Hackathon organized by Burning Heroes. As of 2024, I lead a talented team developing international ride-hailing services at InDrive, collaborating with colleagues from over 15 countries to ensure a seamless experience for riders and drivers worldwide. In particular, I specialize in optimizing driver-sender matches, creating solutions for users to make better deals within our platform, and using the latest cutting-edge technology, such as machine learning and economic principles. Such an approach enhances customer experience and platform efficiency – a win-win for everyone. Why did you choose this field in the first place? I’ve always been fascinated by technology’s potential to solve real-world problems and, most importantly, improve people’s lives. Plus, the fast-paced nature of tech keeps things exciting for me, with new challenges and opportunities to learn emerging technologies. In other words, the field offers a constant learning curve. Besides that, I'm particularly drawn to the collaborative culture where knowledge is shared openly within the tech community. This allows me to create solutions practically for every industry — medicine, AI, real estate — that can impact millions of people worldwide, which truly motivates me. What tech are you most excited/passionate about right now and why? While large language models (LLM) are the most anticipated development, several other technological advancements capture my interest. Here are a few areas I find particularly promising: New technologies, such as advanced biosensors and generic testing, tremendous possibilities for detecting severe diseases like cancer and autoimmune disorders at earlier stages. Additionally, the growing role of big data and its practical interpretation from medical scans (MRI and CT) can lead to better diagnoses, personalized treatment plans, and improved preventative care. In fact, several innovative startups are working in this direction, and I'm eager to see their progress. Healthcare advancements: offer Fully automating back-office processes through AI would benefit tech companies, manufacturers, and other industries. While it may seem ordinary, solving this narrow problem could have a massive impact on industry and enterprises’ efficiency and productivity. AI-powered enterprise automation: Platforms allowing users to create websites without coding are changing how people access technology creation. Recently, an AI tool code and communicated as a software engineer! Just imagine building mobile apps, data dashboards, or even simple workflow tools—all without writing a single line of code. These no-code tools and numerous pilot engineering tools are slowly transforming the landscape, empowering people, and reducing production costs in the digital world. Development through no-code tools: wrote Beyond my interest in the field, the increasing complexity of transportation technologies gives me goosebumps—from self-driving cars and trucks to AI optimization and next-generation predictive analytics. Future of transportation: What tech are you most worried about right now and why? One primary concern about generative AI is the potential misuse of personal data to train these models. Although data privacy regulations are strengthening globally, there’s a lingering suspicion that corporations can still misuse personal data to gain an unfair advantage in the market. This raises a crucial question: Are these regulations compelling, and can the non-tech person understand them? What are your hobbies and interests outside of tech? I enjoy various activities that challenge me mentally and physically in my spare time. Take, for instance, tennis. It is a great way to hone my focus and develop a winning mindset. Its practice also taught me the importance of teamwork and effective conflict resolution. At the same time, psychology is another area I’m passionate about. Currently, I’m delving into Jungian Analysis, which helps me communicate with platform users unbiasedly and glean deeper insights from our conversations. This knowledge and my understanding of cultural differences foster greater empathy — a crucial skill when working on a product used in over twenty countries. I find it helpful to take conversation pauses, ask thoughtful questions, and practice active listening to bridge cultural gaps. Let's talk about breaking the glass ceiling. What were the biggest challenges you faced as a woman in tech, and how did you deal with them? Undoubtedly, the glass ceiling in tech remains a persistent issue, and statistics paint a clear picture – men significantly outnumber women. For instance, women for 25.3% of Google’s new tech hiring in 2023, compared to 20.8% in 2018. At the same time, Microsoft’s workforce to 33.1% in 2023, up from 29.2% in 2018. Other companies, such as Facebook and Apple, showed similar trends. The numbers reveal a stark reality: only one in three women work in the , compared to management, consulting, legal, or finance. accounted rose tech sector Several factors contribute to this disparity. For example, societal expectations can differ for men and women, with women often taking on greater childcare and household responsibilities. Additionally, tech can feel like a male-dominated environment, lacking role models for female leadership and fostering unconscious bias against women leading times in a traditionally masculine style. To navigate these challenges, I choose teams with inclusive cultures and actively support other women in tech. Practically speaking, I am an active participant in communities like Women in Tech that offer invaluable support networks where we can share experiences, empower each other, and curb any misogyny. Though a topic of debate, positive discrimination holds potential in the current landscape. When equally qualified candidates exist, a diverse slate can highlight potential unconscious bias within homogenous environments. The most significant challenge is ascending the corporate ladder within a male-dominated hierarchy. While some advise leveraging charisma to stand out, a more sustainable approach lies in achieving goals through shared objectives and mutual respect. Focusing solely on gender differences can reinforce bias. In contrast, a business-oriented approach fosters collaboration and paves the way for advancement. Any questionable misogynistic story/situation you faced/handled and you want to share with the HackerNoon Fam? While I may not have personally faced misogyny, it's essential to acknowledge that these situations still exist. We've all likely witnessed or heard about them. That's why standing with those who challenge inequality and fight for a more inclusive space is crucial. What's your biggest achievement that you're really proud of? One of my most significant achievements was leading the launch of intercity delivery product, which is now the leader of the mobility market in its country. It resulted in 47.4 million monthly active users by 2023. I managed five teams with numerous stakeholders and oversaw all aspects of the project, from product research to market assessment to financial planning. The product went live in over 100 cities nationwide within several months. In your opinion, why do we see this huge gender gap in the tech industry, and how can we reduce it? As mentioned earlier, the significant gender gap in tech stems from societal expectations and the industry's current culture. To bridge this gap, we need a two-pronged approach. First, we need to cultivate a more inclusive culture within tech. Initiatives like mentorship programs and fostering diverse hiring practices can help. Second, we need to address societal expectations. Normalizing women in tech and providing them with the support they need to balance work and life can create a more equitable future for the industry. Who is your tech idol? Why? Tech is full of inspiring figures, and a few people who stand out for me are Julie Zhuo, Lenny Rachitski, and Paul Graham. Julie's journey from intern to VP of design at Facebook, especially as a minority woman, is a powerful testament to her talent and perseverance. Her recent article on navigating company politics completely changed my perspective on workplace conflicts and empowered me to be more constructive. Sharing valuable insights while in leadership demonstrates her commitment to giving back and helping countless professionals. Lenny Rachitski's insightful product management blog and interviews with industry leaders offer a goldmine of knowledge for anyone in the field. His ability to spark discussions relevant to global communities makes his work exceptionally valuable. I deeply appreciate his contributions - these insights from experienced professionals are invaluable in the market. Finally, Paul Graham's writing on is a constant source of motivation. I often revisit it for inspiration. great work Do you have any advice for aspiring girls who want to join the field? Make sure your passion for this field is the driving force behind your decision. It can be challenging without support, so I recommend building a strong community around you. Look for mentors, participate in online forums, or attend industry events to connect with others. Get real-world experience through volunteering or internships related to your field. The stronger your network and the more you learn, the more opportunities will come. However, it's essential to find something you enjoy. Remember, your career path is yours to define. Don't be afraid to explore and change course if needed. And, finally, believe in yourself – no one can tell you what's impossible.

Normalizing Women In Tech: Interview With Ksenia Mayorova, Leading Product Manager At InDrive

Based on , is an iris biometric cryptocurrency project developed by San Francisco- and Berlin-based Tools for Humanity. Founded in 2019 by OpenAI chief executive Sam Altman, Max Novendstern, and Alex Blania. Wikipedia Worldcoin But if I try to define it with one sentence: Worldcoin is what Bitcoin should have been. Bitcoin was fundamentally conceived as a form of equitable currency not issued by governments but by the community itself. The system eliminates the need for central servers by operating on a peer-to-peer basis. Instead of relying on complex central banking policies, currency generation is governed by a straightforward algorithm. Roughly every ten minutes new bitcoins are created, and through a sort of lottery system, it's determined who receives them. Statistically, this lottery would result in an even distribution over time. The primary issue, however, is the system's complete anonymity, making it impossible to ensure that a participant only enters the lottery with a single ticket. Bitcoin's solution to this problem is the Proof of Work (PoW) mechanism, which requires a certain amount of computational effort for each lottery ticket. However, this leads to a scenario where those with greater computational power have a higher chance of winning, setting a clear path to the inevitable outcome. As usual market dynamics kicked in, nodes began to form groups, and individual nodes stood no chance of winning. Today, less than ten mining farms dominate the network, and thanks to ETFs, Bitcoin has merged into the traditional financial system, becoming just like any other financial instrument. Nothing remains of the anarchist hippie dream; due to its immense energy consumption, Bitcoin is more detrimental to the Earth than beneficial. Worldcoin solved a problem that Bitcoin could not, namely how to ensure the uniqueness of participants while keeping the system anonymous (Proof of Unique Humanness). The Orb To solve the problem, the Worldcoin team developed one of the world's best iris scanners, the rb. O Just like fingerprints, the iris is unique for every individual, making it perfect for proving the uniqueness of a member within a community. Similar to other biometric identification systems, the Orb generates a feature vector based on the iris. This feature vector is characteristic of the individual but does not allow for the recreation of the iris image, ensuring its security (akin to a hash). When we want to identify someone, we regenerate this feature vector. If it closely resembles the original vector within a certain margin (typically cosine distance), the identification is deemed successful. But how does the system remain anonymous? World ID: anonymous proof of personhood is a protocol to bring privacy-preserving global proof of personhood. To achieve this, it utilizes the library, which is based on zero-knowledge-proof technology. Since , I will only briefly describe the system's operation here. World ID Semaphore I have a full article on Semaphore The user generates an Identity Commitment, which Semaphore stores in a Merkle tree. Each Identity Commitment is unique and can have multiple Nullifiers associated with it. To generate a Nullifier, a unique public External Nullifier is required. For each External Nullifier, only one Nullifier can be generated. Thanks to zero-knowledge proof technology (on which ), it can be proven that a generated Nullifier corresponds to an Identity Commitment without revealing the Identity Commitment itself. I also have a full article Let's see how this works in practice using the example of an anonymous voting system. The goal is to ensure that every person with a World ID can only vote once. When a World ID is created in the World App, a unique Secret, and the corresponding Identity Commitment are generated. When someone is identified with the Orb, this Identity Commitment is recorded on the blockchain along with the iris hash, ensuring that a person can only register a single Identity Commitment. Essentially, the Identity Commitment acts like a public key, while the Secret is the corresponding private key used to authenticate Nullifiers. When voting begins, an External Nullifier is generated, serving as the unique identifier for the vote. Each time a vote is cast, the voter generates a Nullifier associated with this External Nullifier and submits their vote. Since only one Nullifier can be generated for each External Nullifier, an individual can only cast one vote. The Nullifier cannot be linked to the Identity Commitment in any way. If another vote is organized, it will have a different External Nullifier, for which the voter will generate a new, unique Nullifier that is completely independent of the one generated for the previous vote. Of course, this solution can be used in any case that requires unique anonymous registration. Use cases: defense against AI bots, Unconditional Basic Income, and Karma money Many might wonder why a blockchain project is interesting to Sam Altman, the CEO of OpenAI. With the advancement of AI, it's becoming increasingly difficult to distinguish bots from humans. There is a genuine concern that, with the help of advanced LLMs, targeted fake information spread on social networks could influence political elections or even the stock prices of companies (as envisioned by the computer in ). This is the primary reason why OpenAI does not release the source code of ChatGPT (at least that's what they claim). A defense against this is to somehow be able to distinguish bots from humans, for which World ID offers an excellent solution. West World Another typical AI-related use case is (UBI). Increasingly, serious consideration is being given to what might happen if, thanks to AGI and humanoid robots, nearly all human-performed work could be replaced by machines. The traditional work-based society would become inoperable, necessitating an alternative approach. Many believe that UBI, where everyone receives income on an unconditional basis instead of through employment, could be the solution. A version of this that operates beyond the control of governments could be a blockchain-based solution, functioning similarly to Bitcoin, but with the generated coins being distributed fairly among people. This wouldn't require massive computational power and significant amounts of energy; proving that we are real humans would be sufficient. The Worldcoin whitepaper specifically mentions the possibility of such a system, with a portion of Worldcoin's WLD tokens being distributed in this manner. However, a separate system dedicated solely to UBI, potentially with its own blockchain that anyone with a World ID could participate in operating, is also conceivable. Similar to Proof of Stake, each block would be authenticated by a node chosen at random, but here the stake is our own identity. This is the hypothetical network I mentioned in the introduction; this would be the "ideal Bitcoin." Universal Basic Income Finally, let me explain why Worldcoin and World ID started to interest me personally. I recently ( ), which operates similarly to the current fiat money system. Currently, banks create fiat money, which generates significant profits for them through interest. In 2008, we saw how poor decisions by banks could devastate the global economy, which also spurred the creation of Bitcoin. In the Karma Money system, individuals and companies lend to each other directly, bypassing banks (P2P lending). Transactions and members' debts are public, so everyone has a reputation. Based on this information, we can decide whether to lend to someone (accept their money) or not. In such a reputation-based monetary system, it's crucial that we can link individual participants' wallets to their identities. Without this, if someone were heavily indebted, they could simply switch wallets and start trading anew with a clean slate, never repaying their debts. However, if the wallet is linked to a World ID, then participants cannot hide their debts. This system could even complement the previously mentioned Universal Basic Income system, where we could spend not only from the income received as UBI but also from credit. published a concept called Karma Money GitHub repo To summarize the above, I believe that Worldcoin is a very exciting project, and if it fully achieves its set goal, namely to become 100% open-source and decentralized, it could become as significant as Bitcoin. Moreover, as I mentioned in the introduction, Worldcoin could be what Bitcoin should have been!

A Brief Introduction of Worldcoin: Proof of Unique Humanness on Blockchain

The Bitcoin halving is slated for sometime around April 19th, 2024. As you might have heard, it follows the Bitcoin supply equation; which is a geometric series terminating after 32 divisions or halvings. In April 2024, we shall have the 4th halving, taking us from 6.25 to 3.125 mined per 10 minutes. BTC The last satoshi shall be mined 32 * 4 years from 2009, which shall be the year 2137. Below is a curve I made in MS Excel modeling the Bitcoin supply equation; Interestingly, however, 3 other equations look like the Bitcoin halving. One equation is behind the most profitable options trading algorithm in the world, one is behind the most powerful energy resource in the world, and one is behind the ability to find the energy in any physical system. More on these below: 1. The Black-Scholes equation The Black-Scholes equation is behind most of the profitable options trading in the world, including Exchange Traded Funds (ETFs) which can be traded like regular options. Multinational companies like BlackRock, which manages trillions of dollars in assets, recently launched a successful product for its investors. Bitcoin ETF Notice the term at the end, Assume an equilibrium situation with: Let the constant number be 5. Thus, we have: Let r be 2 and model as, When graphed, this behaves like the Bitcoin halving, as seen below. Here are similar graphs from other people’s research. 2. The Radioactive Decay equation Radioactivity is the spontaneous decay of heavy, unstable atomic nuclei to form stable nuclei. It is the power behind nuclear fission, the most powerful energy resource on the planet. Interestingly, while radioactivity is so good at releasing gargantuan amounts of energy, Bitcoin is good at absorbing it. But even more, both the Bitcoin halving and the radioactive decay process are exponential functions whose graphs grow in the same way. Consider the radioactive decay equation; The formula is easy enough to be taught to 17-year-olds studying A-level mathematics in High Schools. Now, represents the amount left. If this was Bitcoin, would be the bitcoins left to be mined. A A How about if we track the amount decayed, just like the bitcoins already mined? Easy enough. Subtract from thus; A A_0, Which we can see is similar to what we had before with the Black-Scholes equation. Taking A_0 = 5 and λ = 2, it is the same deal with us modelling y = 5 (1 - e^(-2x) ), hence a similar graph. 3. The Hamiltonian The Hamiltonian, of a mechanical system is defined as the amount of energy contained in the system. H While Bitcoin might be a digital computational system, from what Alan Turing describes in his thesis on a Universal Turing Machine, we can represent any computational system as a mechanical system. Therefore, Bitcoin can be represented as a mechanical computational system. Not that we have the resources to do it on earth. By further extension, classical mechanics can be described in terms of quantum mechanics, hence Bitcoin is a quantum-mechanical computational system. Thus, Bitcoin has a Hamiltonian unknown to us, that can describe its minimum workings absent external complexities and fluctuations in the number of users and miners joining and leaving the network. At the nanoscale, where Bitcoin’s digital dance of the halving resides, the simplest Hamiltonian is the quantum Hamiltonian, represented by hat{H} below. We can see this Hamiltonian operator is part of Schrödinger’s wave equation, fundamental to relating the Hamiltonian with the state of a quantum system at time ; t Notice the term: which is similar to: above. Using Euler’s formula, The introduction of the imaginary component has thrown us off the beaten path of a nice exponential leveling off like the Bitcoin supply equation. We instead get a circle with an angle given by and radius R = 1. i Ht Now let radius R = 1, and take |r| e^(-iθ) to be the common ratio of a geometric series with r being a complex number, |r| < 1 and first term a = 1. The resulting geometric series; can be modeled as a Fourier series hence the graphic below with r = 0.5, a = 1 forming a circle of radius R = 4/3. https://en.wikipedia.org/wiki/File:Complex_geometric_series_animation.ogv?embedable=true#filelinks But what if radius R = 1, as we want? What would common ratio r be? First, we need to know that for the general form of a geometric progression; + + + + + … a ar ar^2 ar^3 ar^4 the sum to n terms, for |r| < 1. The sum to n terms then converges to a unique value as n to infinity. This is because r^n to 0. tends tends Hence, we can summarise as below; Note: Because Bitcoin's supply is capped at 21,000,000 it moves in a circle! This via circularity leveraging its monetary transactions velocity, V, in Irving Fischer's equation → MV = PT *** More wonders From the following are related to the Bitcoin halving; https://en.wikipedia.org/wiki/Geometric_series The expansion of the universe, where the common ratio r is defined by Hubble's constant. The decay of radioactive carbon-14 atoms, where the common ratio r is defined by the half-life of carbon-14. Last but not least, One of my Hackernoon post’s viewership statistics.

The Mathematical Mysteries of Bitcoin's Halving

বিটকয়েনের অর্ধেক হওয়ার গাণিতিক রহস্য

Die mathematischen Geheimnisse der Bitcoin-Halbierung

Los misterios matemáticos de la reducción a la mitad de Bitcoin

Les mystères mathématiques de la réduction de moitié du Bitcoin

बिटकॉइन को आधा करने का गणितीय रहस्य

ビットコインの半減期の数学的謎

비트코인 반감기의 수학적 미스터리

Os mistérios matemáticos da redução do Bitcoin pela metade

Математические тайны халвинга биткойна

Bitcoin Yarılanmasının Matematiksel Gizemleri

Những bí ẩn toán học về việc giảm một nửa Bitcoin

比特币减半的数学之谜

I worked in research all my life, so I know a stereotype that researchers write ugly code (e.g. see , , or ). But I thought: we can fix it, right? So multiple times I tried to design nice research frameworks. I tried to bring in interfaces and create nice abstractions using software engineering books and blogs I liked reading. here here here But over and over again all those efforts went in vain. The majority of research software I worked on never went to production (although some did). It would have been great for my mental health if someone told me a simple truth: . Researchers should not spend much time engineering it in the first place. dying research code is actually what is supposed to happen Professional software engineers always look down on researchers who are not using the best software practices. There are several posts trying to raise the bar of research code (e.g. this and a ). But this post goes other way around: it argues how to not overdo the best software practices and instead invest only in fast exploration. It is targeted for research-oriented companies where your goal is to try out many ideas fast. great post research code handbook 1. Take on some strategic tech debt A successful research project at a company has two phases: exploration and exploitation. In “exploration” you want to try out as many diverse solutions as you can. During “exploitation” you have to robustify the best solution and turn it into a useful product. Optimal software practices are quite different between the two. That's why companies often have separate research and product divisions. All the books you might typically read on software design are mainly about the second "exploitation" phase. In this phase you are building foundations for a scalable product. This is where all the design patterns come in: nice APIs, logging, error handling and so on. But in the first "exploration" phase you are building foundations that will live forever. In fact, if the majority of your efforts survive, then you (by definition) did not explore enough. not Many practices in this post are examples of what would normally become “tech debt”. It’s what you get by not writing clean reusable well-abstracted code. Is debt always bad? We prefer never getting a loan or a mortgage, but borrowing money is often a good strategy in life. It's ok to get into debt to move fast and profit later. Similarly, by not taking technical debt you might be slowing down your research. The good news is that the majority of the time you don’t have to pay it back. Most of your research code is likely to die anyway. So on average, you will not be suffering from the whole tech debt you've taken. The case against code reuse Many software architectures and refactoring techniques are specifically oriented to improve code reusability. There are generic to code reuse. But in production they are outweighed by the well-known benefits (for example, see ). In research projects, the majority of the code is destined to sink to oblivion. Striving for code reuse could actually slow you down. downsides this typical post Limiting code reuse is the type of technical debt that is ok to take in research. There are several patterns of code reuse I want to discuss: adding an unneeded dependency, copypasting code, maintaining a lot of shared research code, premature design investments. Think twice before importing something new If you know a well-maintained versioned library that is going to speed you up - go for it! But before taking in a new dependency, try to make a judgment call whether it’s worth it. Every additional one brings you closer to dependency hell. It makes you invest time into learning and troubleshooting it. See more pitfalls of dependencies in this . concise post It’s probably fine to depend on something if: you used it already, there is not much to learn, it has a large community, good docs and tests it is versioned, easy to install and finally, there is no way you can implement it yourself. But be wary about a dependency if: you can’t figure out how to use it quickly, it is very new (or very old) or no one seems to know about it; there are no docs or tests it is from your monorepo and is constantly being changed by other teams it pulls in many other dependencies and tools; or it's just hard to install and finally, you feel that you (or some LLM) can write this code in a few hours. Instead of an explicit dependency, you can follow a nice Go proverb: “ ", which is our next topic. a little copying is better than a little dependency Copypaste gives you freedom of experimentation Some say that “ ”. But to my surprise I found myself arguing in favor of it quite often. Copypaste could be the optimal choice during the exploration phase. copy-paste should be illegal If you depend on a heavily-used function from another part of the codebase you can forget about easily changing it. You’re likely to break something for someone and have to spend precious time in code reviews and fixes. But if you copypaste the necessary code into your folder, you are free to do anything you want with it. This is a big deal in research projects where experimentation is a norm rather than an exception. Especially if you are not sure if changes are going to be useful for everyone. I find that deep learning codebases are suitable for copypasting the most. Typically, the amount of code needed to describe a model and its training is not so huge. But at the same it could be very nuanced and hard to generalize. Shareable training scripts tend to grow to an unmanageable size: e.g. Hugging Face has +4k lines. Interestingly enough, transformers opted for copypaste on the model level. Please check out their with the reasoning behind their "single file model" policy. See more resources about the beauty of copypaste at the end. transformers Trainer post An alternative to copypaste is staying on a branch. But I feel like it brings too much overhead in teamwork. Also, I found several more posts about the beauty of copypaste - see more posts in the conclusion. Maintaining shared research code is hard Maintenance of heavily used shared code requires a lot of work. Take a look at the number of file lines plotted against the version. You can see that even the most advanced research teams struggle to keep the complexity in check. torch.nn.Module Pytorch Don’t underestimate time and resources needed to maintain a large shared research code. The more a research library is used the more complicated it becomes. It happens faster than for a typical library because every research direction has a slightly different usecase. Establish very strict rules of what could be contributed back. Otherwise, the shared code becomes fragile and overgrown with a slew of options, buggy optimizations and edgecases. Since the majority of research code dies out, all this extra complexity will never be used again. Dropping some of your shared code will free up some time to do actual research. Design for exploration, not for code reuse It is somewhat true that you don’t want too much even in production. Try to implement the simplest possible solution that meets the requirements. But in production code there are always aspects of maintainability to consider. For example, error handling, speed, logging, modularization is what you typically need to think about. to future-proof your code In research code, none of that matters. You just want to quickly prove that an idea is good or bad in the fastest possible manner and move on. So the dirty simplicity that achieves it without any modules or APIs is totally ok! Don’t waste valuable time on premature software investments such as: creating component interfaces too early in the project. You'll spend too much time fitting into self-made artificial constraints optimizing deep learning training infrastructure before committing to deep learning solution using production config/factories/serialization systems or base classes. Quite often you don't need their functionality during prototyping overly-strict linting and type checking systems. No reason to slow down fast-changing throw-away research code. 2. Invest into fast exploration The goal of a research project is to find a novel solution. No one knows (by definition) what it looks like. It is akin to an optimization process in a complicated research landscape with limited information. To find a good minimum, you need to try many paths, recognize good and bad paths and not get stuck in local minima. To do all of it fast, you sometimes need to make software investments instead of taking tech debt. Speed up common paths There are several different research paths you want to try. Is there a design, a library or an optimization that would shave off time from the majority of paths? You should be careful to not over-engineer anything because you don’t always know all the ideas you’re about to try. This is very custom to every project, but here are some examples: if you train deep networks, invest into training infrastructure. Figure out hyperparameters allowing you to converge during training quickly and reliably if every experiment requires you to use a different model, figure out how you can quickly swap them (e.g. by using a simple factory system or just copypaste) if every experiment has too many parameters and is hard to manage, invest into a nice configuration library. Branch out quickly Researchers should be able to initiate new diverse ideas quickly. It seems easy at the start of the project. But then it gradually becomes harder and harder as people get entrenched in their favourite research paths. To address this, cultural and organizational changes are essential. There should be a process stopping non-promising research before sinking too much money and emotion into it. Regular demo days and technical peer reviews can serve as effective strategies for this purpose. It's also important to find a balance between people jumping on a new shiny idea and properly closing current projects. But this is a software post, so here are some practices to make branching out new projects easy: keep evaluation code disentangled from algorithms. Evaluations are typically more stable than research directions embrace starting a new project from a blank slate, but then watch out which components are reused. Modularizing and cleaning them up is a good investment in a new research project, implement the most innovative and risky component first. Doing so identifies the majority of bottlenecks guiding future software design. Increase signal to noise ratio Noisy and buggy code makes results so ambiguous and inconclusive that the whole project is going to be a waste of time. While you shouldn't over engineer things, you can easily follow these simple rules of thumb to avoid messy code: avoid code with side-effects default to functions rather than classes; and with classes, prefer encapsulation vs. inheritance minimize length of functions/classes/modules; minimize number of if-statements know python well, but use simple techniques. Resist the temptation going into intellectual weeds of metaclasses, decorators and functional programming. Software that produces different results during different runs is tricky to work with. If you made an important but wrong decision based on an unlucky seed, you are going to waste a lot of time recovering. Here are some tips when dealing with non-deterministic software: understand whether noisy is coming from the algorithm or it's evaluation. Noise sources compound and you should strive for completely deterministic evaluation. don’t stop finding sources of randomness until you really get a reproducible script. Remember that after finding all random seeds, noise might come from data or from generic functions with side-effects. vary seeds and determine baseline variance of your results. Don’t take decisions on non-statistically significant results. Conclusion The punchline comes from about research code: this post . “You don't bother with [good software design] because the code is not the point. The code is a tool that gets you the answer that you need” It is extremely important to have great coding foundations. But at the end of the day, the exploration and actually useful product is what matters. If you use too much production software in research, you waste time needed to discover something new. Instead, find what slows down your exploration process. Speed up research paths by investing in fast branching, time to results and clean noiseless code. It would be crazy to argue completely against code reuse. I just want to point out that code reuse should be a well-balanced activity. In research, the ratio of throw-away code is larger than in production. The balance is tilted further against reuse. Here are few more great posts with pitfalls of code reuse: Reusable Code: The Good, The Bad, and The Ugly When It Makes Sense to Repeat Yourself Balanced StackExchange with pros and cons of reuse And here are few more posts arguing for copypasting practices: Is copypaste really a problem? When Should You Copy-Paste Code? The Good and the Bad of Copy-Paste Programming "As a senior with 5 YOE, I feel like part of my pay is knowing what code to copy lol" Thank you for reading! I feel some bits are a bit controversial, please let me know in the comments! Also appears . here

SLATE

slateteams.com

-- employees

Since n.d.

COMPANY RANKING

SLATE

EVERGREEN INDEX #589

Representing this company? Click here to claim and customize this page!

Slate WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

SLATE

slateteams.com

-- employees

Since n.d.

COMPANY RANKING

SLATE

EVERGREEN INDEX #589

RELATED COMPANIESRANK

STORIES ABOUT SLATE

Representing this company? Click here to claim and customize this page!

Slate WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!