Hi! I’m Shaked Lokits,
Technically 

Winning Arguments Thanks To ChatGPT How AI Could Change The Face Of Online Debate As someone who loves to engage in political discussions, I’ve always been passionate about sharing my opinions and debating with others online. But as the political climate became increasingly divisive, I found it difficult to keep up with the fast-paced and often heated arguments in the comment sections of various websites. That’s when I discovered ChatGPT, a language model that helped me argue with people online. ”No longer did I have to spend hours researching and crafting the perfect response” With ChatGPT by my side, I was able to quickly respond to arguments with well-reasoned and logical responses. No longer did I have to spend hours researching and crafting the perfect response because ChatGPT was able to do it for me in a matter of seconds. Arguing Is Finally Easy For example, when someone commented that “the policies of the current administration have led to record low unemployment and a booming stock market”. ChatGPT generated a reply that pointed out the long-term effects of the current administration’s policies and how they disproportionately benefit the wealthy! In response to a comment claiming that “climate change is a hoax” ChatGPT was able to provide a response that highlighted the overwhelming scientific consensus on human-caused climate change and the risks of failing to address this—impressive reasoning—critical global challenge. And when someone argued that “the government should stay out of healthcare” ChatGPT could generate a reply that emphasized the government’s responsibility to protect the public health and ensure access to affordable and high-quality healthcare for all. The End Of Authenticity? ”The use of AI in online discussions raises questions about the authenticity of the internet” The use of language models like ChatGPT in online discussions raises important questions about the authenticity of the internet. As more and more people will turn to AI-powered tools to help them argue their points, the line between human and machine-generated content may become increasingly blurred. This could lead to a situation where it becomes difficult to determine the origin of a comment or response, undermining the trustworthiness and credibility of online discussions. If you’re someone who loves to engage in political discussions but finds it difficult to keep up with the fast-paced and often heated arguments in the comment sections, I highly recommend giving ChatGPT a try. It just might change the way you argue forever.

In the past few weeks there’s a topic I find difficult to approach without imagining my doctor bugging me about my blood pressure. Which is why I’ve decided to tell everyone about it, so let me get you up to speed. A Brief History Of Timeouts It was July of 1969, and the landing module of the Apollo II was about to leave the moon, sadly their memory buffers had them doing it uncomfortably quick. Apollo 11 Command Module On-Board Voice Transcript Ah, yes, the grand space era where engineering really shined brightest, seeing up and coming ad-hoc solutions seeping deeply into our day-to-day habits. One of those, as we see, was the timeout methodology, in which if you failed to run a specific electronic circuit over a specific timeframe then you’d break the entire task circuit, to recover onto a new circuit flow. This is where the term circuit breaking comes from, like Apollo’s famous life support circuit breaker that saved their lives. The original broken circuit breaker switch from Apollo 11. The Museum of Flight in Seattle, WA. Servers and Workers Since then, we’ve managed to push the bounds on memory and processor utilization. And in the era of communications we were feeling free to create C/Java/Python/Ruby servers that took a long time to perform consecutive tasks on separate thread-workers without having to worry about recovery flows. We would simply tag erroneous jobs in the database, kill the worker and go on with our lives, technically putting aside the worries of infrastructure-mandated time-out limits. Oversimplified task worker server Serverless Lambdas So, we all got really cushy in our CRUDs, Threads and Restful everything environments but this was not very economical, so we’ve said the thing that makes the most sense. ”If we can run a container on any environment, and I only need to run a single function, then why not do that” And that, as any friend would tell you about buying an old car, “was a great idea at the beginning“ We can fully rely on an event-driven cloud environment which would only run our most atomic functions, when we need them, if we need them. A real game changer for the digital era. Extremely oversimplified serverless infrastructure, but we need some pictures because we all have ADD But What About The Timeou… If only we weren’t so greedy and used the lambdas for what we were aspiring. Minimal functions that reduce operational overhead costs but no, “What if we ran an entire express server inside it?” you asked, glibly, and added ”That’s technically a function, isn’t it? We only need to deal with this pesky timeou…”. Why You Should Use A Server Okay, I’m done ranting, which brings us to our issue; Sometimes, you should use a server. And it’s not a matter of style, a technical lenience, or a personal preference, it’s a matter of necessity. Derive From Usage Not Preference I think by this point it’s pretty obvious what bothers me, looking at it from a utilitarian point of view, all code runs on some sort of computer. Whether we’re simulating them for a few minutes(lambdas) or running them “indefinitely”(servers) is a crucial implication to the overall design of our codebase, which means that we cannot fully decouple these two decisions. What Should I Do? You Ask This means that if we expect a piece of code to have an extensive complexity footprint, we should either break it down to smaller functions which could be used as a smaller lambda function or use a server which would be able to orchestrate this load. Now I know that tools such as the sam cli and others are awesome, I love them as well and the ease that they provide but this should not dictate our architectural needs. So let me give you these rules of thumb If you need a task orchestrator, use a server If you have long-running tasks that you can’t/won’t break up, use a server But if you only wish to run the router of a server, still, use a server If it’s not a function, you guessed it, use a server If you want to run a server, use a server Basically, if your lambda was too complicated to debug, you reached a hard timeout, missing a good orchestration mechanism, could not recover from a failed state without rerunning your entire task, or you just don’t understand the benefit of lambdas in your architecture. I beg you, use a server. 15-Minutes-Driven-Development, Or Why You Should Use a Server was originally published in Melio’s R&D blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: It doesn’t matter how good your technical writing is unless someone is reading it. This is how you do it. It’s 10 minutes into the meeting and my watch is warning me about my heart rate (thanks.) “I can’t believe this is the first time I’m meeting the new vice president” — I was thinking — “how did it come to this, we made it so clear in our documentation that this would be a big issue, they had months to prepare, didn’t they?..” This is my story about TL;DR, how it became my stepping stone to communication, and why you should use it. So Why Is This Relevant? I have a very strict regimen on technical documentation — won’t go into detail but — it’s usually around 25 pages, split into technical, product and stakeholder sections. Kind of a “cover all bases, leave none alive” mentality to project planning. The only drawback was the minor issue of people not reading my work. Even though I wrote a designated section for each and every person, even though I told the story, it still came to a point where people were just not reading, and I don’t blame them: Technical writing is hard to read, it’s so…technical, that there has to be a really good reason for me to read that “Be careful” section. Enter: Too Long, Didn’t Read “Too Long, Didn’t Read”, or TL;DR, is a short description — the gist — of an upcoming piece of text which helps you to decide if you’d like to read it. You might have seen it on social media blog-posts or other short-form content. It’s basically a snippet to hook the reader in. ”With the irony being that we used tl;drs less, although we needed them more” Between the years 2004 and 2014 the use of tl;dr blossomed. This was an era of long-form personal blogging which began to die down with the introduction of Medium as a publishing platform for amateur writers. This encouraged a shorter and more professional form of writing, with the irony being that we used tl;drs less, although we needed them more. This showcases interest over time of TL;DR on google trends. Note the change following the introduction of Medium. How Can I Possibly Summarize Everything? The honest answer is that you can’t, you wrote that long message for a reason, but then again, summarizing isn’t what this is about. Instead, try to capture the reason why a person should read what you wrote. It might sound difficult but I find that most reasons boil down to: Building common ground: “There is no way you could advance without this pre-existing understanding” Warning about risks: “This and that are going to break real soon, if it relates to you then read on” Exposure to opportunities: “Have you heard about that new thing that makes your life easier?” And it’s not only easy to sum things down this way, it also assures that you nearly always hit the mark when it comes to getting people to continue reading. Location, Location, Location So I ended up adding that TL;DR to my document and that was it. If only…it took less than a day until the stream of endless questions kept pouring in — “But how could it be?? Didn’t they read my tl;dr?” — I asked, to which the reply was clearly: No. “What I ended up doing was adding it to everything I wrote that would take longer than a minute to read” Apparently it’s not enough to tl;dr the documents, because it doesn’t promise you that people will read your messages, nor your meeting notes. What I ended up doing was adding it to everything I wrote that would take longer than a minute to read. Now I know it sounds like a lot so don’t take my word for it. A study published in 2012 revealed that the chances of a message being read decrease by 71% after a minute of reading. That’s all folks Sorry if it was too long to read, but trust me, you will now be a better communicator. But let me leave you with some food for thought. The Book of the Dead is an ancient Egyptian manuscript filled with spells — yikes — a dead person would need for the afterlife. It is usually placed inside a mummy’s coffin and begins by warning about the terrible agony that would be inflicted upon anyone who wouldn’t read it. Now, isn’t that a great TL;DR? From the Papyrus of Hunefer (c. 1275 BCE). This shows the scribe Hunefer’s heart being weighed on the scale of Maat against the feather of truth, by the jackal-headed Anubis.Visit our career website Two Minutes From Now, You Will Communicate Better was originally published in Melio’s R&D blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

"Industrialize" follows the story of children who grew up during the age of the industrial revolution. It is based on diaries and letters written by children who were admitted to Dr. Bernardo's Home in the 1870's.Taking form to illustrate the repercussions and necessities that rose with the industrial revolution. The model was created as a singular tome which then served as the basis for the comics.

EscalationEmerging from the rigorous and repetitive mundanity we all experience, this model was produced procedurally out of a single fractal spline. Animation included, the “perfect" generation was made to inspire the ordinal tendencies we enlist into our lives.

The Nowhere is a comic story, created especially for mobile reading. The project intends to examine how the mobile phone’s affordances can enable a unique reading experience, available only in this medium. It tells the story of a monk's past lives through bits of his memories stored in his belongings. Each memory tells a short story from his life, and each offers a unique reading capability enabled only in this format.

and the issues of starting something new Writing the first post always poses a difficult step, on one hand you wish for it to be inspiring and inviting and on the other hand you wish it would be practical and interesting. Either way, your demands are unproportional for any blog post and so, you postpone it for a year or two. Jackson Pollock once said, when asked why are his painting so chaotic, that if he would try and think the perfect brush stroke he would never paint a single picture. Jackson Pollock — Autumn Rhythm It doesn’t make much difference how the paint is put on as long as something has been said. Technique is just a means of arriving at a statement. — J.Pollock So I decided to open a blog, my name is Shaked Lokits and I have many stories to tell, a lot of projects to share and some well founded anecdotes on life. I am currently a triple major student for Computer Science, Visual Communication and Education with the main goal of the disrupting the formal education system. This is my first post.

In "Welcome to Stanistan" you play as the manager of Stanistan’s social media department, trying to increase the tourism in the imaginary failing country, using promotions on Instagram and choosing very carefully what to include in the picture or what filters or hashtags to use. Since the country itself is in constant distress there is no way to win but to play that fake game we all play on social media, using that cold, plastic happiness to hide the warmth and humidity of tears that are ruining our make-up.