Eatiquette rides on the mega trend that consumers are growing increasingly conscious about the food they put in their bodies, concerns that are often linked to the ingredients in these foods

Eatiquette

First and Last Things by H. G. Wells, is part of the HackerNoon Books Series. You can jump to any chapter in this book here . POSSIBILITY OF A NEW ETIQUETTE POSSIBILITY OF A NEW ETIQUETTE. These two ideas, firstly the pupil-teacher parental idea and secondly the democratic idea (that is to say the idea of an equal ultimate significance), the second correcting any tendency in the first to pedagogic arrogance and tactful concealments, do I think give, when taken together, the general attitude a right-living man will take to his individual fellow creature. They play against each other, providing elements of contradiction and determining a balanced course. It seems to me to follow necessarily from my fundamental beliefs that the Believer will tend to be and want to be and seek to be friendly to, and interested in, all sorts of people, and truthful and helpful and hating concealment. To be that with any approach to perfection demands an intricate and difficult effort, introspection to the hilt of one’s power, a saving natural gift; one has to avoid pedantry, aggression, brutality, amiable tiresomeness—there are pitfalls on every side. The more one thinks about other people the more interesting and pleasing they are; I am all for kindly gossip and knowing things about them, and all against the silly and limiting hardness of soul that will not look into one’s fellows nor go out to them. The use and justification of most literature, of fiction, verse, history, biography, is that it lets us into understandings and the suggestion of human possibilities. The general purpose of intercourse is to get as close as one can to the realities of the people one meets, and to give oneself to them just so far as possible. From that I think there arises naturally a newer etiquette that would set aside many of the rigidities of procedure that keep people apart to-day. There is a fading prejudice against asking personal questions, against talking about oneself or one’s immediate personal interests, against discussing religion and politics and any such keenly felt matter. No doubt it is necessary at times to protect oneself against clumsy and stupid familiarities, against noisy and inattentive egotists, against intriguers and liars, but only in the last resort do such breaches of patience seem justifiable to me; for the most part our traditions of speech and intercourse altogether overdo separations, the preservation of distances and protective devices in general. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. H. G. Wells (2009). First and Last Things: A Confession of Faith and Rule of Life. Urbana, Illinois: Project Gutenberg. Retrieved October 2022, https://www.gutenberg.org/files/4225/4225-h/4225-h.htm This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

POSSIBILITY OF A NEW ETIQUETTE

“Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators...” - Github In this article, I’ll delve deep into the mystical art of submitting and reviewing Pull Requests (PRs), with a focus on the following three key areas: Preparing your PR. Receiving feedback on your PR, and Giving feedback on someone else’s PR. I’ll also include some useful resources that have inadvertently helped me along my Pull Request journey thus far. These principles apply to all software developers, regardless of experience level. My Love Hate Relationship With PRs I recently reached the 100 PR milestone in one of the main Ruby on Rails repositories we have at , the company I have been plying my trade at for the past two years. Zappi Despite the fact that submitting PRs is such a regular occurrence in my life as a software developer, this seemingly trivial act can still be quite a daunting exercise for me. Especially when I am working on a complex feature or navigating a particular area of the codebase that I am not completely comfortable with. Opening yourself up for criticism and judgement is an extremely vulnerable activity that has the potential to impact you either positively or negatively. And when you are an HSP (highly sensitive person) like me, just a hint of destructive criticism not only has the potential to derail your day but also your self-worth as a human being, your entire life’s purpose, and your career as a software developer as a whole. Ok... slight exaggeration, but you get my point. In order to counteract my heightened sensitivity to judgment and critique, I have come to understand that there is a pattern that defines a good PR and I have realized that following a core set of principles when handling PRs - regardless of whether you are the submitter or the reviewer - will result in a much smoother process for all parties involved. Why are PRs important? There are a number of reasons why PRs are important, with the most important being that you need another set of eyes to critically analyze the changes that you are about to introduce. When you are developing software, whether it is a new feature, a refactor, or a bug fix, what usually happens is that you have been looking at your code for so long, and over this period of time, you have gradually allowed yourself to see the world from a very specific viewpoint. While this is expected, it is slightly dangerous because this viewpoint of yours is often riddled with blind spots and confirmation biases, that are often reinforced by the . Getting feedback from others via a PR, allows you to break away from this pattern of thinking. Dunning-Kruger effect The act of having other developers, regardless of whether they are more or less experienced than you, review your code, provides you with an opportunity to receive well-rounded feedback that you can either act upon or use to further confirm your approach and rationale. Step 1: Preparing your PR “Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.” ― Robert C. Martin, Clean Code 1. Write presentable code This should be one of the golden rules of coding in general: write presentable, concise code that makes sense. This simple act will make everybody’s life easier. Over the course of your career you will read much more code than you will write, so it is absolutely imperative that you ensure others can read and understand the code that you yourself write. Your code needs to be clean. It doesn’t need to look complicated. It doesn’t need to be verbose or superfluous. It doesn’t need to be composed of fancy, extremely obscure, complex, hard-to-read one-liners. You are not participating in a coding challenge, you are contributing to a shared repository. Thus, your code needs to get the job done, nothing more, nothing less. It needs to have meaningful method/variable names. It needs to follow the conventions of that particular repository. It needs to be readable, and all in all, it just needs to make sense. 2. Add detail to your PR description Your code should be concise but your PR description doesn’t have to follow that same principle. I prefer to write and read PR descriptions that offer as much detail as possible, obviously, in a readable, formatted, presentable manner. Your description should tell me what you are doing, why you are doing it, and in certain situations, it should also provide an outline of the how as well. After I read your description, I shouldn’t have any more questions, doubts, or uncertainty. If it is a new feature, add a link to the ticket that describes the user story and briefly touch on the technical implications of the changes you made. If you are fixing a bug then detail why the bug was happening in the first place and what you have done to fix it. If you are making a change to anything visual, then include a screenshot where possible. If there are many visual changes as part of a new/changed workflow, then drop a link to a pre-recorded video either in the PR or on the ticket. If you have done a refactor to the database or added some new tables, then throw in a UML class diagram. When someone reviews a PR, before they look at a single line of your code, they should have the full context of what they are looking at and why these changes were made. Your PR description is your opportunity to provide that context. 3. Keep a clean commit history As a developer, you should cultivate a habit of committing regularly in logical chunks, with commit messages that make sense. It will help you out in the future when you are looking back and trying to figure out what happened and when. Even if you squash all commits before merging in your branch, you still shouldn’t code as if you are participating in some arbitrary hackathon. 4. Get feedback as soon as possible There is no rule in software development that states that you should only submit a PR when the work is complete. No, not at all. In fact, one of the joys of PRs is that you can submit one whenever you want. It is never too early to submit a PR. So if you are working on a complex change, if you are not too confident about your approach, or if you want to get approval of your thought process and rationale from your peers, then you should submit a PR early, maybe even throw in a to-do list for transparency. Just make sure you make it clear in your title or description. You can also use a custom label like “WIP” (work in progress) or “DO NOT MERGE”. The benefit of the early PR approach is that your reviewers will show even more empathy towards you because you are basically saying “hey guys, I’m not too sure about this approach, but this is what I am currently thinking, please let me know your thoughts.” All the points I have mentioned above will still apply to your draft PR. Even if it is not yet complete, it should still be clean, concise and presentable. 5. Notifying people about your PR You need to have an effective way of informing the rest of your team that your PR is ready. On top of this, you need to ensure that your team has incorporated PRs into it’s day to day workflow so that no PR can be easily overlooked. I’ve encountered many instances where a PR has been waiting to be reviewed for days on end to no avail. In our team (The Oilers), we manage PR transparency and communication with a combination of a “Ready for Code Review” Jira Swimlane that we talk about during standup every day, as well as a minimal-noise slack channel dedicated solely to PRs. Step 2: Receiving Feedback 6. Leave your ego at the door The first piece of advice I would give when it comes to receiving feedback is to leave your ego at the door. Try your best not to bring emotions into the process, and don’t be so sensitive about the code just because you wrote it. The more objective you are throughout, the easier it will be. I realized that I was dragging my ego into my PRs the day I caught myself being super defensive over code I had copied and pasted from another file. It wasn’t even my code, yet I was still being so protective of it. #smh 7. It is code that you wrote, it is not who you are You’ve spent hours, days, weeks, maybe even months working on this code, and naturally, you’ve probably formed some sort of emotional attachment to it. This is understandable, we are software developers, this is what we do. But in spite of this, you should fight the urge to identify yourself and your self-worth with the code you have written. You need to understand that the feedback you receive is for the benefit of the codebase, the product, the team, and the company as a whole and it is not a direct critique of your personal self-worth or your overall value in the world. So don’t take things personally. Take it on the chin and move on. “I don’t believe people wake up in the morning saying ‘who can I treat poorly today?’. Always assume positive intent.” - Mary Frances-Winters 8. Always assume the best intentions One thing I have repeatedly noticed when it comes to interpersonal relaying of information is that text-based communication can be extremely ambiguous. When people are interacting in person there are a lot of nuances that one can easily pick up on, which are not equally transferrable when interacting via text, and this makes it very easy for any plain text comment to be taken the wrong way. Because of this, I would advise that, as a premise, you should always assume the best intentions of others, unless given an explicit reason to do otherwise. 9. Don’t leave people hanging Contrary to popular belief, developers are people too, and we would greatly appreciate it if our efforts and opinions are respected and acknowledged. So when you receive feedback on your PR, be ready to act upon it in a timely manner. Either implement the feedback or engage the reviewer in a respectful conversation explaining why you chose to do what you did and why you think it’s the better approach. But don’t let people’s reviews go to waste. If you don’t think something is important/relevant, that is fine but don’t silently disregard it. 10. Don’t hesitate to reach out If you see a comment that you don’t fully understand, don’t hesitate to ask for a more detailed explanation. Sometimes, we software developers tend to treat our interactions with other people as if they have an all-year-round VIP pass to the inner workings of our prefrontal cortex. So we will drop a vague comment that makes complete sense to us, without taking into consideration the fact that other people might not be on the same wavelength as us. When this happens, just reach out and ask for clarity. 11. Ensure you preserve the context A PR lives on forever, so it is important that you keep all the context in there when possible. If you start a conversation in a PR, do your best to keep that conversation there so that it is easy for other people to follow. This is important because at any point in time there could be multiple people reviewing the same code both in the present moment and in the future, long after it is merged in. So you should do your best to ensure everyone is still in the loop. I can recall a number of occasions where a thread from a PR has escalated into more synchronous forms of communication like a Slack conversation or a Zoom call. And when everything is said and done I will be sure to drop a comment on the PR, either summing up what was discussed or just simply stating that it was discussed, before resolving the thread. Step 3: Giving Feedback 12. Avoid ad hominem criticism Your task is to provide feedback on the code/design/approach, not the person. You should never confuse the two. If you do happen to have a personal qualm, then that should be handled elsewhere, not on a PR. 13. Be aware of the context Make it a point to take the context of the situation into consideration. Yes, you should always be consistent in your reviewing, but how you present your feedback shouldn’t be entirely agnostic of the person that requested the feedback. For example, how you respond to a developer who is very experienced in that codebase might not be exactly the same as how you would respond to a junior who just started programming in Ruby a week ago. A general rule of thumb that applies to all forms of communication is that you should always empathize with your target audience as much as possible. 14. Don’t be afraid to ask “why?” Within the realm of problem-solving, “Why” is one of the most important questions that one can ask. You should never think that it will make you look ignorant, or that it will undermine the person who wrote the code. PRs should be seen both as an opportunity to critique and an opportunity to learn. So if you see something you don’t understand, then ask why that is happening. Simple as that. To this day there are parts of our repositories I am very active in, that I still haven’t seen. My exploration of our code is akin to humanity’s understanding of the deep-sea, where there are literally new species being discovered every year. On the other hand, asking why also encourages people to question their beliefs, their rationale, and their approach. Often we developers (AKA hackers) do things simply because “this is just how it’s done”, “this is what was there before”, “without this it doesn’t work”, or simply because “StackOverflow said ...”. And as a result of this inertia, sometimes you will find that developers don’t have a valid answer to the “why” question that you have posed. When this happens it means there is a much more pressing issue at hand. 15. Don’t feel pressure to approve If you don’t feel comfortable approving a PR then don’t. It’s ok to disagree with an approach and to withhold your approval. Every opinion is valid and you shouldn’t feel any pressure or obligation to push something through if you are not fully convinced. Just be sure to communicate this effectively. 16. Don’t be afraid to come across as pedantic When reviewing PRs, you should feel free to leave comments and suggestions despite how minor you think they are. Don’t ever be afraid of being regarded as pedantic. As the proud Grammar Nazi that I am, I will not hesitate to correct your typos, fix your grammar or sort out your punctuation. I’ll even add spaces, and remove unnecessary new lines in all the places that either you or your linter overlooked. Yes, I am aware that it’s a code review and not an English essay submission, but as a writer, I take great pride in all forms of communication, regardless of whether I am creating or consuming. I don’t discriminate, and neither should you. One day, years from now, the repository will be in a much better place because of you and your uncompromising attention to detail. 17. Leave room for preference When it comes to giving PR feedback there is a fine line between subjectivity and objectivity. And as a software developer, you must be cognizant of where that line is. Just because you would do something in a certain way doesn’t necessarily mean that is how it should be done. Different people tend to have different opinions, and in some situations there might not be a ‘right’ way to do something, and that’s ok. 18. Beware of the bystander effect I have seen some big PRs in my life and I have been intimidated by them. But I have come to realize that even the big PRs need some loving. Big PRs are PRs too. So you should not procrastinate by continuously putting it off, or thinking that “another developer will do it”. Just bite the bullet/eat the frog. The world will be a better place after you view all 347 of those files. 19. Review as many PRs as you can Reviewing PRs is a win-win for both parties, so it is important to review as many as you can. By reviewing a PR you gain more context about what is happening in the codebase, and the developer who submitted the PR has the benefit of having an extra pair of eyes view their work. It is vital that you incorporate regular PR-reviewing-time into your weekly schedule, because those PRs will not review themselves. 20. Don’t be so serious! At the end of the day, it’s just a PR, so don’t be so serious. You should always make room for banter because good quality banter makes the world a better place. So don’t think that you need to always be super serious in the comments section of a PR. Yes, you should be professional and yes, you should always keep it #SFW, but there is always room for a joke, some sarcasm, and some kick-ass emojis. Alright, there you have it, my core PR principles summed up into one article. If you have any interesting PR learnings that you would like to share with me, then drop a comment below. To read more of my articles you can check out my . Otherwise, happy coding my fellow developers. The world is your oyster, go forth and prosper. blog Resources: Preparing your PR: - Robert C. Martin Clean Code: A Handbook of Agile Software Craftsmanship - David Thomas, Andrew Hunt The Pragmatic Programmer: Your journey to mastery Receiving feedback: - Brene Brown The Power of Vulnerability - TedEx Why incompetent people think they're amazing Giving feedback: - Dale Carnegie How to Win Friends & Influence People - Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler, Laura Roppe Crucial Conversations: Tools for Talking When Stakes Are High

Pull Request Etiquette: 20 Core Principles For Handling PRs As A Software Developer

Photo by on . Olu Eletu Unsplash I feel extremely lucky to have been instructed in the basics of Git-etiquette from essentially the first day in my journey to become a software engineer (Thank you, !). A seemingly minor concept, was one of the first things taught to me as a budding developer, and accordingly I placed upon it the importance that was conveyed to me in that education. Krailo Surprisingly, it seems to me that there are many developers who appear to be unfamiliar with the of possibly the most ubiquitous tool in software development, Git. Since many programmers learn Git on-the-job, they are likely not coached in best practices for something considered more of a soft-skill, and it’s doubtful that anyone chooses to use poor git-etiquette. Nonetheless, the problem is still rampant amongst developers of all skill-levels. dos and don’ts Don’t worry though, the solution will not require hours of reading and completely changing your workflow. In fact, it’s a fairly easy problem to solve, and it just requires that you follow some easy to remember guidelines. So let’s get started with a few of the basics. Knowledge and implementation of these concepts will help you make the first steps from greeny-junior to Git-guru. Use the CLI and an editor… ..and stop using git commit -m “Useless message here" Trying to fit a well-formed commit message into a single command doesn’t work. A commit message is supposed to take a minute. You should have to stop and reason about the work you just did in order to explain it to others who may work on the project as well as you future self should you need to revisit these changes. Writing a well-thought-out message is your way of writing into “history” the changes you have made and explaining what you changed, and why. When you take the time to compose your messages in a text-editor window(as opposed to on the command line) it will cause you to slow down and make sure your changes are complete and worth sharing, as well as allow you to be more descriptive in your explanation of why the changes were necessary. When you use the editor to compose messages, it can help catch errors in your code much sooner. For example, I use the git aliases in my work flow. The command expands into which will open your default editor with a summary of your current changes in the form of comments. What’s staged, what isn’t, untracked files, and a diff of the changes you are currently committing, allowing you to review the changes as you are writing your commit message. Oh-My-Zsh gc git commit --verbose Reading through the diffs before you write your message can save you from committing ‘debugger’ code and/or help spot a typo/spelling error that normally wouldn’t get caught until code review. : Tip Follow proper commit message format The Title-line When composing a title-line, I try and follow : 3 rules The title-line starts with a capital letter, is 50 characters(or less), and has no punctuation at the end. It should be in the imperative voice. i.e. ‘Add new About Us page’ or ‘Refactor tests for the order model’ It should correctly complete the sentence, “If accepted, this commit will <your commit message goes here>.” A super-basic commit message using proper grammar and structure. (`git commit — verbose` usingNeovim) The Body A brief summary of the changes. If the changes were simple enough they can be understood with just a “Title” line then you may opt out of this section(the above picture is a good example of changes that don’t need a detailed explanation). The body should explain the “what” and the “why” for your changes, not the “how.” Anyone who reads the code should be able to discern how you implemented your change. Use the body section to cover the parts that might not be so obvious. An example of pretty thorough commit messages with explanatory body sections If you are using a ticket system(Trello, Jira, etc.), . It’s a nice reference to have for anyone reviewing your PRs who may be unfamiliar with the issue or for other developers working on the same project. Tip: management INCLUDE THE LINK TO THE CARD/ISSUE Be atomic and keep changes together in related commits Group like changes together in the same commit Not even close to logical grouping Don’t throw some config changes and new CSS in the same commit. Break things apart in a logical manner.(Remember, even if you do more than one chunk of changes at a time, you can still commit them in a sensible manner, grouped by like-changes) The same changes from the previous image, but broken out into more “atomic” commits. Your commits show the progression of your code. Make it a story that is easy to follow. Even if it doesn’t seem important right now, being able to follow the history of your code can help you locate the source of regressions through logical deduction( ). that JS error in the console likely isn’t from the commit where you updated CSS and changed some icons in the footer The Git log from a feature I recently worked on. This by no means is all you need to know to use git masterfully, but it is a solid foundation from which to build. Knowledge of your and how best to use them is just one facet of becoming a high-quality developer. Attention to these “small” things will help you become more productive, and make working with you much more enjoyable. Even if the only person reaping those benefits is ten-weeks-from-now-You. tools Yes, something as small as the form of your commit messages may seem unimportant or tedious, but attention to the small things and fostering good habits is key to success. “We are what we repeatedly do; Excellence, then, is not an act but a habit.” — Aristotle For further reading, check out: This which, along with , are the sources for most of the material in this article. blog post by Tim Pope this blog post by Chris Beams for is a definite read. Caleb Thompson’s article Thoughtbot must The book . === “Pro Git” by Chacon & Straub GitBible s by Atlassian is frequently my go-to reference for some of the more advanced git-topics(**really solid examples and explanations**). This set of tutorial If you liked this article, please hit that 👏 button and consider following me. The more people that show interest in what I write about, the more likely I am to keep producing. Thanks!

“Git” it together: Some tips on commit etiquette and best practices for junior developers

I don’t have an particular themes from the week I can remember in enough detail to discuss this week, so thought it time I dragged out one of my long term ‘topics to discuss’. A couple of years ago I wrote a piece for and after experiences from the past six months in Berlin it seemed time to revisit, update and revise this post. Many of the points in the original post still apply, I’m supplementing them here. The Fetch on Meetup Etiquette I’m going to discuss general topics that apply to everyone and every event, then specifics to meetups, other events, attendees, speakers and organisers. Just to be clear, this isn’t aimed at any particular people and I’m not saying that I am always right or that I always even keep these rules myself. It’s just general good (I hope) advice based on my years of experience attending, speaking at and organising events. RSVPs This has become increasingly worse as meetup (more the platform than the concept) has become more popular and looking back at my original post I have to revise my reliable percentage for attendance. This is especially true with groups and events as they grow larger and there seems to be something of a break point at about 50 attendees. Anything less than this number I would say you can expect about 60–70% attendance, higher than this, maybe 30–40%. I attended an event late last year with 170 RSVPs and maybe 60 attendees. This is just plain rude and offensive to your (typically volunteer) organisers, it takes no effort whatsoever to update an RSVP. I would like to add that if you aren’t going to attend an event update your RSVP with as much notice as possible. Busy events tend to have people on a waiting list, but freeing them up a space 10 minutes for an event is likely too short notice for most people. Keeping on Time or Run Late Gracefully This applies to everyone at every event, if you’re too busy to arrive on time then consider not coming at all. I understand that shit sometimes happens and if you still think it’s worth attending, attend quietly and gracefully. In most cases, attendees arriving late is not that much of a problem, but if you are a speaker then it’s far more crucial. Plan how long it will take you to get somewhere and setup to start on time and add twenty minutes to it for good measure. Ensure you know how long your presentation will take, get to the point, stick to point and leave enough time for questions if they are part of the format. The same applies for organisers, try to keep to time. Some attendees may have a long journey home, early starts the next day or child care arranged. Whilst personally I would love it if events started and finished a little earlier, that’s my personal preference, many are relying on the times stated in a description, so stick to them. If this means prodding speakers to also stick to time, then that’s fine, it’s their responsibility to also respect the times stated. Food and Drink I wont add much more here to extend my original post, the only point I want to add is special diets. (amongst other services) and have we experience catering other events in the past. We have heard just about every dietary requirement there is and there’s always a way to accommodate it. If you do have a particular dietary requirement, please tell organisers about it and they will likely do as much as they can to accommodate you, don’t expect it to be catered for automatically. Equally, if you can no longer attend, keep organisers informed so that the food specially acquired for you isn’t wasted. Often organisers of conferences ask if attendees are Vegetarian , Vegan etc and organise food to match those numbers. Please if you didn’t ask for one of those special meals, then leave them for those who did or they might go hungry. My company provides catering to tech events Questions are not for general statements People are getting better with this point than they used to be, or maybe that’s just because I don’t attend as many activism groups as I used to. A question is just that, a sequence of words with punctuation suited to giving a response. It’s not space for you to give your general opinion on things or promote what you do. If you want to do that, then write a blog or give a presentation. Speakers or facilitators should also try to keep answers appropriately long to answer the question but leave enough time for other questions. Bear in mind that not everyone is confident at putting there arm in the air to ask a question, or they may be short, keep a keen eye open for those in the audience trying to ask questions who may not be as clear as others. Respect the WiFi We all know how infamously bad wifi can be at events, especially conferences, where there is never enough bandwidth or coffee. If Wifi is provided, respect it. Turn off Dropbox and other similar file syncing software, don’t use this opportunity to torrent or download large files or stream video. Unless you need to, connect just one device to the wifi and bear in mind that there may be international attendees who need to make use of the wifi more than you as it’s their only option. Spatial Awareness in Tight Spaces I don’t know if this is an increasing problem with everyone or just that I associate with a lot of people who lack spatial awareness, but keep an eye around you. Tech folk tend to bring large bags with them everywhere, keep an eye on them, they can nearly double the size of your body sticking out behind you, where there is likely someone standing or walking. Events are for meeting people and of course you will want to speak to others. When congregating, don’t do it in busy access points such as doorways, the middle of hallways or anywhere else that blocks the flow of people. You may have something important to discuss, but adding 2 minutes to find somewhere considerate to discuss it wont lessen the importance of the topic. Bottles and other Rubbish I have noticed at events in Germany how prone attendees are to knocking bottles over. I’m not sure what it is about German tech folk, but during every talk you will hear at least two bottles clanking to the ground, which is incredibly loud and distracting. If you are not confident enough in your own spatial awareness then hold on to your bottles and even better, if your finished, throw it away. Keeping on top of your rubbish also helps with the end of event clean up, if it’s half complete already, then that’s less work for the (likely volunteer) organisers. Be Nice to Strangers Lots of events now have codes of conduct and these are a fine addition to our events that give a more binding agreement between everyone to respect those around you and provide a more comfortable environment to those who may have historically been put off attending. There’s one group of attendees these codes of conducts don’t address and that I have found treated far worse at European events than events I attended in the UK or Australia. People you don’t know. Whilst there are specific events just for meeting people, often people attend other more specific meetups and events for the same reason, to meet others with common interests. When you attend an event, don’t just associate all night with people you know, if you see a stranger on their own, go over and introduce yourself and have a chat with them. Microphone Technique This is one just for speakers. Learn how to use a microphone, it’s not hard and will vastly improve your presentation. Don’t tap the microphone to see if it’s on, it’s an annoying noise and rest assured that once you start talking, people will let you know if it’s not working. A microphone goes in front of your mouth, not your chin, don’t fear it, unless you’re speaking in a poorly wired building it wont bite. Look at the shape of the head of a microphone, there’s waves emitting from it in that shape that pic up your voice, speak into them. If you use a microphone properly you won’t need to shout but (at some point) learning to project properly annunciate and speak clearly will help level up your presentation game if that’s something you want to pursue. Demos and Code Examples If you’re giving a technical talk then it’s likely you want to demonstrate something and that’s fantastic, a demo is a great way of showing a concept or idea. But demos are also renowned for going wrong, no matter how many times you tried them before hand. My main advice is to keep the demo local as much as possible and one tool that is exceptionally useful for this is virtualisation such as Docker or Vagrant. You can setup a whole isolated virtual setup that can be then removed afterwards without affecting your machine. If it’s not possible to have a local demo (for example demonstrating big data or large server set-ups) then consider making a video instead, you know it will work. In fact always have a backup video for every demo. If you’re showing code, show it in a readable colour combination and font size, preferably clearly laid out and bear in mind that projectors often have notoriously poor contrast, so stick with clear, strong colours. Gendered Language This is an odd one and i’m not sure if it’s advice or an observation. When I attend events in English speaking countries, people nowadays tend to remove as much gendered language as possible, going out of their way to not mention ‘he’ or ‘she’, but instead use gender neutral language. As English is a loosely gendered language this is easy for native or fluent speakers as English doesn’t need gender for context or understanding. As I’ve moved more amongst presenters who’s native languages do have gender I have noticed a tendency for them to use it when they also speak English. Of course if they are speaking their native language then it’s a different story and I’m not qualified enough to discuss the relevance of adding a gender when describing a person in a narrative, because with many languages it’s expected and needed. But, whenever I hear someone overuse ‘guys’ or gendered language when speaking English at events that are sensitive to these issues, I can’t help but squirm. As I don’t want to criticise someone speaking a language that isn’t their own I don’t want to push this issue too much, but bear it in mind as it’s easy to strip gender from English without losing anything even though it may not feel natural to everyone. Further Advice for Speakers I presented at Write the Docs in 2015 with some specific advice for speakers which contains some of the advice above and a bit more, . you can see it here . Rant Over Time for you to tell me your peeves and advice for improvement at meetups and events. Podcast All of the Weekly Squeak posts are accompanied by a podcast where I go more in-depth into the topic, subscribe here . I’m travelling the next few days, so the episode that accompanies this post will be available later this week.

Meetup and Conference Etiquette Revisited

The urge to delete Social media and messaging apps have created new avenues for people to enter our lives. You might feel the urge to delete someone for various reasons – annoyance, personal growth, or just a shift in content preferences. In a world where change is constant, the desire to curate our online circles reflects this innate need for control and authenticity. Personally, I’ll admit this urge is like an automatic response. Most of the time, it feels cathartic, a satisfying release, and a digital refresh. Other times, it’s how my fear expresses itself, and it helps me feel protected from a perceived threat. Our patterns of behaviour Research into deleting phenomena unveils a tapestry of human behaviour. Deleting certain individuals may lead to the emergence of hidden aspects of ourselves while fostering deeper connections with others. Though deleting generally refers to removing someone from your friends list or connections, it varies depending on the platform. Subtle differences between notifications and accessibility reflect how we engage with each other on these platforms. For example, Facebook carries more emotional weight due to stronger personal connections, while LinkedIn is a professional disconnect. Instagram is more towards social exclusion, while Twitter ranges from negligible to significant, sometimes leading to being silenced within an online community. Over time we’ve learned to sculpt a more intricate inner world, rich with nuance and layers. This creates a maze around our identity where fragments are selectively revealed — a new freedom that also questions our accountability. The power of perception Attention is currency, so the act of deleting carries weight beyond the digital realm. The energy behind our gaze and thoughts can shape the way we perceive and interact with others online. Deleting someone from our virtual sphere doesn’t diminish the impact of our attention, it redirects it. As connections add up over time they weave a complex web of relationships. Being perceived by this network is a novel phenomenon, expanding beyond our immediate physical surroundings to include individuals from anywhere. Engaging with this vast array of minds, each with their own belief systems presents a challenge that transcends our ability to fully comprehend. Tip: Try to visualise your network, what kind of groups are there? What shapes emerge? Express this in a way that feels natural to you, draw it out or write about it. Navigating conflicting emotions Deleting can stir a mix of conflicting emotions – jealousy, loneliness, and misunderstanding. Leaning into these feelings can help you learn about yourself. Perhaps jealousy points you to something you want to do in your life. Feeling misunderstood by your current group of friends might motivate you to take the leap into new groups. Then there’s the possibility of the deleted individual finding out, would they care? Would you care? Try to simulate meeting them in real life, how would you feel and what would you say to them? I’ve found it quite freeing to admit to people about deleting. It takes courage and humor, but it also opens up an opportunity to talk about digital spaces and our personal needs. Remember: digital etiquette is different for everyone, and by acknowledging the complexities of human interaction we can make it more enjoyable. Exploring your digital maze The act of deleting people is both a reflection of our evolving selves and a tool for self-preservation. Growth and change are normal for us, yet our need to hold on accumulates an unnatural web of connections. By embracing the nuance of digital relationships and remaining mindful of our intentions, we can navigate the intricate maze of human connection with a bit more clarity and compassion. Stay tuned for more posts and future webinars, shedding light on the intimate quirks of our digital existence. Much love ₊˚⊹♡ The urge to delete The urge to delete Social media and messaging apps have created new avenues for people to enter our lives. You might feel the urge to delete someone for various reasons – annoyance, personal growth, or just a shift in content preferences. In a world where change is constant, the desire to curate our online circles reflects this innate need for control and authenticity. Personally, I’ll admit this urge is like an automatic response. Most of the time, it feels cathartic, a satisfying release, and a digital refresh. Other times, it’s how my fear expresses itself, and it helps me feel protected from a perceived threat. Our patterns of behaviour Our patterns of behaviour Research into deleting phenomena unveils a tapestry of human behaviour. Deleting certain individuals may lead to the emergence of hidden aspects of ourselves while fostering deeper connections with others. Though deleting generally refers to removing someone from your friends list or connections, it varies depending on the platform. Subtle differences between notifications and accessibility reflect how we engage with each other on these platforms. For example, Facebook carries more emotional weight due to stronger personal connections, while LinkedIn is a professional disconnect. Instagram is more towards social exclusion, while Twitter ranges from negligible to significant, sometimes leading to being silenced within an online community. Over time we’ve learned to sculpt a more intricate inner world, rich with nuance and layers. This creates a maze around our identity where fragments are selectively revealed — a new freedom that also questions our accountability. The power of perception The power of perception Attention is currency, so the act of deleting carries weight beyond the digital realm. The energy behind our gaze and thoughts can shape the way we perceive and interact with others online. Deleting someone from our virtual sphere doesn’t diminish the impact of our attention, it redirects it. As connections add up over time they weave a complex web of relationships. Being perceived by this network is a novel phenomenon, expanding beyond our immediate physical surroundings to include individuals from anywhere. Engaging with this vast array of minds, each with their own belief systems presents a challenge that transcends our ability to fully comprehend. Tip: Try to visualise your network, what kind of groups are there? What shapes emerge? Express this in a way that feels natural to you, draw it out or write about it. Navigating conflicting emotions Navigating conflicting emotions Deleting can stir a mix of conflicting emotions – jealousy, loneliness, and misunderstanding. Leaning into these feelings can help you learn about yourself. Perhaps jealousy points you to something you want to do in your life. Feeling misunderstood by your current group of friends might motivate you to take the leap into new groups. Then there’s the possibility of the deleted individual finding out, would they care? Would you care? Try to simulate meeting them in real life, how would you feel and what would you say to them? I’ve found it quite freeing to admit to people about deleting. It takes courage and humor, but it also opens up an opportunity to talk about digital spaces and our personal needs. Remember: digital etiquette is different for everyone, and by acknowledging the complexities of human interaction we can make it more enjoyable. Exploring your digital maze Exploring your digital maze The act of deleting people is both a reflection of our evolving selves and a tool for self-preservation. Growth and change are normal for us, yet our need to hold on accumulates an unnatural web of connections. By embracing the nuance of digital relationships and remaining mindful of our intentions, we can navigate the intricate maze of human connection with a bit more clarity and compassion. Stay tuned for more posts and future webinars, shedding light on the intimate quirks of our digital existence. Much love ₊˚⊹♡

Deleting People Online: Liberating and Conflicting

My 30-Day Journey on a Dark Web Marketplace That Belonged to a Cyber Gang

একটি ডার্ক ওয়েব মার্কেটপ্লেসে আমার 30-দিনের যাত্রা যা একটি সাইবার গ্যাং এর অন্তর্গত

Meine 30-tägige Reise auf einem Dark Web-Marktplatz, der einer Cyber-Gang gehörte

Mi viaje de 30 días en un mercado de la Dark Web que perteneció a una banda cibernética

Mon voyage de 30 jours sur un marché du Dark Web appartenant à un cyber-gang

डार्क वेब मार्केटप्लेस पर मेरी 30-दिवसीय यात्रा जो एक साइबर गिरोह से संबंधित थी

サイバーギャングが所有するダークウェブマーケットプレイスでの私の30日間の旅

사이버조직이 속한 다크웹 마켓플레이스에서의 30일간의 여정

Minha jornada de 30 dias em um mercado da Dark Web que pertencia a uma gangue cibernética

Мое 30-дневное путешествие по торговой площадке даркнета, принадлежавшей кибербанде

Siber Çeteye Ait Karanlık Web Pazarında 30 Günlük Yolculuğum

Hành trình 30 ngày của tôi trên thị trường web đen thuộc về một băng nhóm mạng

我在网络帮派暗网市场中的 30 天之旅

In recent years, headlines have been flooded with reports of cybercriminals arrested for orchestrating ransomware attacks and employing extortion tactics. Despite awareness and efforts to combat these threats, ransomware gangs continue to thrive, reaping profits from their activities. This begs the question: How are ransomware gangs as profitable as they are? The evolution of Ransomware into a service. Ransomware has undergone a dramatic evolution since its inception in the 1990s. Originally, it was largely a one-off endeavor, with cybercriminals conducting isolated attacks targeting individual users. However, as technology advanced and cyber defenses improved, ransomware tactics also evolved. Fast forward to the present day, ransomware has transformed into a sophisticated and lucrative business model, generating billions of dollars in illicit profits annually. Ransomware-as-a-service (RaaS) platforms give access to ransomware tools, allowing even those with limited technical expertise to launch attacks in exchange for a share of the ransom payments. This combination of technological advancements, economic incentives, recruitment tactics, and offering support to victims has turned ransomware into a multi-billion-dollar industry, making it a significant threat to individuals, businesses, and critical infrastructure worldwide. Trust is a hard concept. The rise of Ransomware-as-a-service (RaaS) platforms has democratized access to ransomware tools, allowing cybercriminals of varying skill levels to participate in extortion schemes. Raas provides everything from ransomware code to payment processing services, enabling affiliates to execute attacks in exchange for a percentage of the ransom proceeds. This model has lowered the barrier to entry for cybercrime, resulting in an influx of new actors entering the ransomware crime syndicate. RaaS platforms have revolutionized the ransomware business and actually reflect standard business practices and operations. One such business practice is the support options that are available to victims. Ransomware groups have transformed their operations into sophisticated support services for their victims. These services extend beyond providing ransomware code and include technical assistance, customer support, and even negotiation services. Victims can access dedicated forums or communication channels such as TOX, where they can speak with support about any issue or issues they are facing. Some sites offer a detailed description of how to use their support system including the use of proper etiquette. Another example is the mission statement of Ransomware groups. Despite their illicit nature, ransomware groups often display their mission statements through their actions and communications. While they may not articulate their objectives in formal documents or public declarations, their actions speak volumes about their goals and motivations. For instance, the targeting of specific industries or organizations can indicate a desire to maximize financial gain or exert influence over critical infrastructure. In essence, ransomware groups convey their mission through their actions. Show me the money!!! At its core, ransomware is a lucrative business venture for cybercriminals. The potential for high profits with relatively low risk has attracted individuals and organized groups alike to engage in ransomware operations. With the ability to target a wide range of victims, including individuals, businesses, and even critical infrastructure, the financial rewards can be substantial. “Joining the alliance advantage” option can gain you 90% of the payment. All that is needed is your Bitcoin wallet address as a payment method. They will pay you first and they will take their 10%…you may go to prison but that is the risk of success, I guess. Just like the cybersecurity job market, cybercriminals are offering high salaries and assorted perks to attract the best for the job. Some job ads have annual salaries of as much as $1.2 million for the most skilled cybercriminals. Other positions include attack specialists, reverse engineers, testers, analysts, and administrators. In an article published by “Just as any other business, cybercrime needs labor. New team members to participate in cyberattacks and other illegal activities are recruited right where the business is done – on the dark web. We reviewed job ads and resumes that were posted on 155 dark web forums from January 2020 through June 2022 and analyzed those containing information about a long-term engagement or a full-time job.” securelist.com Below is an organizational chart workflow of how recruits would function. “A total of roughly 200,000 employment-related ads were posted on the dark web forums during the period in question. The largest number of these, or 41% of the total, were posted in 2020. Posting activity peaked in March 2020, possibly caused by a pandemic-related experienced by part of the population.” income drop Below are examples of Job postings resumes that ranged from a diverse group of individuals looking for various forms of work on the dark web. Don’t pay and you will pay. The transition to extortion in ransomware was a significant move in profitability for cybercriminals. While traditional ransomware attacks involved encrypting data and demanding payment for its release, extortion tactics expanded the scope of potential victims and increased the potential for higher payouts. By exfiltrating sensitive data before encrypting it, ransomware gangs gained leverage over victims, threatening to expose or sell the stolen information if ransom demands were not met. This approach proved to be more lucrative for several reasons. Firstly, victims faced the double threat of data loss and reputational damage, making them more likely to comply with ransom demands. Secondly, the value of stolen data could far exceed the ransom amount, especially for organizations storing valuable intellectual property or sensitive customer information. The attack on Change Healthcare was an example out of many where Ransomware cybercriminals used extortion to turn more profit. According to “This development is likely to lead to more sophisticated and advanced extortion methods. For example, rather than relying solely on encrypting a company’s data for ransom, Eagan said she expects hackers will employ double or even triple extortion strategies, encrypting sensitive data but also threatening to leak or sell stolen data unless their ransom demands are met. With so much going on, Thakar said the cybersecurity landscape continues to be a cat and mouse game: “Companies come up with a better way to defend, the bad guys figure out another way to go after businesses.” cnbc.com The Pheonix and the Hydra. When law enforcement agencies such as the FBI take down a website associated with ransomware operations, cybercriminals often execute their disaster recovery (DR) plans. These plans typically involve redundant infrastructure, decentralized communication channels, and backup mechanisms to ensure continuity of operations in the event of disruption. In response to takedowns, ransomware groups may leverage their networks and resources to quickly bring the website back online, either through alternative hosting providers, mirror sites, or through peer-to-peer communication protocols. Moreover, the takedown of a major website like Lockbit can serve as a rallying point for cybercriminal communities, prompting them to unite their efforts in restoring operations and retaliating against law enforcement actions. This coordinated response highlights the agility and adaptability of ransomware groups in the face of regulatory scrutiny and underscores the ongoing challenge of disrupting their illicit activities. According to “LockBit is now running from backup servers and has a new Dark Web presence after their site's recent takedown by the FBI and international partners”. techrepublic.com In conclusion, the resilience and adaptability of ransomware gangs, coupled with their sophisticated business model and operational strategies, have solidified their status as the highly profitable business of cybercrime. Their ability to communicate with other criminals and victims, coupled with their ability to restore operations swiftly following law enforcement takedowns, underscores the challenge to the world. Despite continuous efforts to combat ransomware, the nature of these operations, fueled by the potential for substantial financial gain and the anonymity afforded by cryptocurrencies, suggests that ransomware is a threat that is unlikely to disappear anytime soon. The Cybersecurity world will always be the phoenix rising from the ashes as ransomware gangs are the hydra remaining constant even when one head is removed…another takes its place.

Risky Business: Decrypting the Profitable World of Ransomware Operations 

Get ready for an AI earthquake! A team of UCLA researchers ( n, , , ) have dropped some major keys to AGI. It's not only the code to seriously human-sounding AI, but they've also gone and open-sourced the whole thing. @zxche @Yihe__Deng @HuizhuoY @Kaixuan_Ji_19, @QuanquanGu Now you can develop better LLMs without needing to feed it tons of new, human-annotated data. First, let's focus on the game-changer here: a self-teaching language model. This method lets a language model becoming better and better without massive amounts of new, externally curated data. teach itself, Introducing SPIN: Self-Play Fine-Tuning Converts Weak Language Models to Strong Language Models I went full deep-dive mode – read their paper (" "),  scoured the insights on forums like , , and with Google Gemini Ultra and GPT-4 Turbo – and the core concept of SPIN knocked my tech-loving metaphorical socks off: Self-Play Fine-Tuning Converts Weak Language Models to Strong Language Models HackerNews X Reddit The 'Conversation Partner' Trick Imagine starting with a language model that has mastered basic skills (let's say conversational etiquette). With SPIN, the model building a dataset from what it already knows. generates internal 'conversations,' Instant knowledge expansion! Step two involves unleashing a new model and giving it one task: spot the difference between and genuine human communication. This forces the original model to up its game, getting more and more with every response to avoid detection. machine-generated chats human-like Here's where things get interesting. They started with (already fine-tuned with ). SPIN unleashed an iterative training system with this base model, improving it exponentially without relying on tons of new externally created data. zephyr-7b-sft-full UltraChat corpus SPIN vs. Traditional AI Training (DPO): A New Champion? We usually think machine learning, particularly for these huge language models, requires boatloads of carefully curated and labeled data. methods involve humans painstakingly rating AI responses against each other for training. Not only is this labor-intensive, but it also balloons costs as a dataset grows. Direct Preference Optimization (DPO) Direct Preference Optimization (DTO) is a training method where a model is fine-tuned using a dataset of preferences, often involving human judgments that decide which of the model-generated responses are preferred. This method requires collecting new data where each piece is labeled based on these preferences, which can be resource-intensive. In contrast, SPIN utilizes , significantly reducing the need for new data. iterative self-play By the first iteration, , highlighting its efficiency and effectiveness in leveraging existing data to enhance model performance. SPIN's performance already exceeds that of DPO in most cases SPIN showcases its strength by achieving . The process of , methodically enhances the model's performance across multiple iterations, , especially on challenging benchmarks like TruthfulQA and GSM8k. on-par performance with models trained on more extensive datasets iterative training showcasing substantial improvements So, SPIN outperforms conventional training methods, including DPO, by efficiently leveraging synthetic datasets generated through self-play, without the need for additional human-annotated data. What are SPIN's Strengths and Costs? SPIN throws a curveball with its self-play dynamic. Think of it like a language model sparring with itself in a linguistic boxing ring, with each round teaching it new tricks. SPIN's data efficiency bypasses the need for new human-annotated datasets. But more importantly, it , . accelerates the improvement loop making the model increasingly adept at generating human-like text Not only does SPIN seem to match models trained on larger external datasets, but its iterative power means consistent gains as it essentially studies its own output. Mindblowing, right? Okay, Let's Talk the Elephant in the Room – COST Nous Research co-founder has a point. These big ol' language models don't get smarter for free. Iteratively re-training with SPIN involves the expensive process of Supervised Fine-Tuning (SFT) each time. @Teknium1 However, he also mentions that "I think its worth it!". Also, the long-term benefits of quicker evolution and potentially less dependency on human-annotated data outweigh the initial investment? That's the exciting question! BOOM! It's Open-Source AI Time Just yesterday, , associate professor of computer science at UCLA and director of AI research at ByteDance, announced that . This doesn't just mean code and datasets, but pre-trained models to kickstart your own AI journeys. Quanquan Gu anyone can now use the SPIN model and dataset SPIN mirrors human thought processes. By generating text that feels human, SPIN hints at the foundational elements of reasoning that future AI could do. You know how some LLM outputs feel robotic right? Well, SPIN is different. It actually mirrors the way humans think. The way it writes feels so natural, it's like a peek into how future AI might be able to reason for themselves. This isn't just about making chatbots sound nicer. It's about creating a kind of digital thinking that works like ours. That kind of AI would be so much more flexible and capable of real understanding. While SPIN is a big leap forward in making language models sound more natural, . it's easy to get excited and overestimate what it means The text it produces is impressive (you can take a look to the database), but it's important to remember that AI doesn't yet have the capacity for true independent reasoning. While SPIN isn't true , the way it mimics human-like writing demonstrates impressive advances in how AI could process and use language in the future. AGI Even so, it does suggest amazing possibilities for how AI and language might develop in the future (if you remember that we are at the beginning of the hockey stick, the future is not far from today...) The ripple effects will be huge and here's your access pass: Code: Available on : GitHub https://github.com/uclaml/SPIN Data: Hosted on , the dataset is readily accessible for those eager to apply SPIN methodologies: Hugging Face https://huggingface.co/collections/UCLA-AGI/datasets-spin-65c3624e98d4b589bbc76f3a… Models: Pre-trained models are also available, offering a head start for experimenting with SPIN-enhanced language models: https://huggingface.co/collections/UCLA-AGI/zephyr-7b-sft-full-spin-65c361dfca65637272a02c40… Project Page: For comprehensive insights and further information, the project page is an invaluable resource: https://uclaml.github.io/SPIN/ To sum up, its iterative, self-improving methodology is a significant advancement towards creating LLM that can engage in genuinely human-like communication. Originally shared on my . X account

AGI Blueprint? UCLA Researchers Open-Source SPIN—A Self-Improving Language Model

এজিআই ব্লুপ্রিন্ট? UCLA গবেষকরা ওপেন-সোর্স স্পিন—একটি স্ব-উন্নতিশীল ভাষা মডেল

AGI-Blaupause? UCLA-Forscher Open-Source-SPIN – ein sich selbst verbesserndes Sprachmodell

¿Plan AGI? SPIN de código abierto de investigadores de UCLA: un modelo de lenguaje que se mejora a sí mismo

Plan AGI ? SPIN open source des chercheurs de l'UCLA : un modèle linguistique auto-améliorable

एजीआई ब्लूप्रिंट? यूसीएलए शोधकर्ता ओपन-सोर्स स्पिन-एक स्व-सुधार भाषा मॉडल

AGIブループリント? UCLA の研究者がオープンソースの SPIN — 自己改善型言語モデルを公開

AGI 청사진? UCLA 연구원 오픈 소스 SPIN - 자체 개선 언어 모델

Projeto AGI? SPIN de código aberto para pesquisadores da UCLA - um modelo de linguagem que se aprimora automaticamente

Проект AGI? Исследователи Калифорнийского университета в Лос-Анджелесе SPIN с открытым исходным кодом — самоусовершенствующаяся языковая модель

AGI Planı? UCLA Araştırmacıları Açık Kaynak SPIN—Kendini Geliştiren Bir Dil Modeli

Bản thiết kế AGI? Các nhà nghiên cứu của UCLA SPIN mã nguồn mở—Mô hình ngôn ngữ tự cải thiện

AGI 蓝图？加州大学洛杉矶分校研究人员开源 SPIN——一种自我改进的语言模型

EATIQUETTE

eatiquette.io

-- employees

Since n.d.

COMPANY RANKING

EATIQUETTE

EVERGREEN INDEX #3653

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

Eatiquette WIKI

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

EATIQUETTE

eatiquette.io

-- employees

Since n.d.

COMPANY RANKING

EATIQUETTE

EVERGREEN INDEX #3653

RELATED COMPANIESRANK

STORIES ABOUT EATIQUETTE

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

Eatiquette WIKI

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