• Most votes
  • Most comments
  • Newest
  • Activity
    1. I have found this to be a semi controversial topic. Its almost becoming a required point for getting a new job to have open source work that you can show. Some people just enjoy working on...

      I have found this to be a semi controversial topic. Its almost becoming a required point for getting a new job to have open source work that you can show. Some people just enjoy working on programming side projects and others don't want to do any more after they leave the office.

      Whats your opinion on this? Do you work on any side projects? Do you think its reasonable for interviewers to look for open source work when hiring?

      16 votes
    2. @francescoc: It is with great sadness that I share news of Joe Armstrong's passing away earlier today. Whilst he may no longer be with us, his work has laid the foundation which will be used by generations to come. RIP @joeerl, thank you for inspiring us all.

      20 votes
    3. Previous challenges It's time for another coding challenge! This challenge isn't mine, it's this challenge (year 5, season 3, challenge 3) by ČVUT FIKS. The task is to design a network...

      Previous challenges

      It's time for another coding challenge!

      This challenge isn't mine, it's this challenge (year 5, season 3, challenge 3) by ČVUT FIKS.

      The task is to design a network communication protocol. You're sending large amount of bits over the network. The problem is that network is not perfect and the message sometimes arrives corrupted. Design a network protocol, that will guarantee that the decoded message will be exactly same as the message that was encoded.

      MESSAGE => (encoding) => message corrupted => (decoding) => MESSAGE
      

      Corruption

      Transmitting the message might corrupt it and introduce errors. Each error in a message (there might be more than one error in a single message) will flip all following bits of the message.

      Example:

      011101 => 011|010
      

      (| is place where an error occured).

      There might be more than one error in a message, but there are some rules:

      • Minimum distance between two errors in a single message is k

      • Number of bits between two errors is always odd number

      According to these rules, describe a communication protocol, that will encode a message, and later decode message with errors.

      Bonus

      • Guarantee your protocol will work always - even when errors are as common as possible

      • Try to make the protocol as short as possible.

      8 votes
    4. Hello everyone! It has been a while since last programming challenge, it's time for another one! This week's goal would be to build your own interpreter. Interpreter is program that receives input...

      Hello everyone! It has been a while since last programming challenge, it's time for another one!

      This week's goal would be to build your own interpreter.

      Interpreter is program that receives input and executes it. For example Python is interpreted language, meaning you are actually writing instructions for the interpreter, which does the magic.

      Probably the easiest interpereter to write is Brainfuck interpreter. If someone here doesn't know, Brainfuck is programming language, which contains following instructions: ,.<>[]-+. Other characters are ignored. It has memory in form of array of integers. At the start, pointer that points to one specific memory cell points to cell 0. We can use < to move pointer to left (decrement) and > to move pointer to right (increment). . can be used to print value of cell the pointer is currently pointing to (ascii). , can be used to read one character from stdin and write it to memory. [ is beggining of loop and ] is end of loop. Loops can be nested. Loop is terminated when we reach ] character and current value in memory is equal to 0. - can be used to decrement value in memory by 1 and + can be used to increment value in memory by 1. Here's Hello World:

      ++++++++++[>+++++++>++++++++++>+++>+<<<<
      -]>++.>+.+++++++..+++.>++.<<++++++++++++
      +++.>.+++.------.--------.>+.>.
      

      People with nothing to do today can attemp to make an interpreter for the Taxi programming language.

      You can even make your own language! There are no limits for this challenge.

      23 votes
    5. I'm looking for a cheap small factor mechanical keyboard. I love the looks of XD64 or a JJ50. How do i go about it? I Don't want the numpad, don't care about leds and prefer more retro/sober...

      I'm looking for a cheap small factor mechanical keyboard. I love the looks of XD64 or a JJ50. How do i go about it? I Don't want the numpad, don't care about leds and prefer more retro/sober styles than the ones with wings and dragons and lasers blazing across the keys.

      I live in Brazil, so i'll have to import everything. I'm looking to buy everything from one place if possible.

      I was looking at KPrepublic. What do i need for the xd64?

      1. Plastic case
      2. Key caps
      3. XD64 PCB with gateron switchs (Kit 10)

      Do i need plate and stabilizers? It's already $91 without it. If it's necessary, i think it would be a better idea to just buy a Durgod Taurus k320 since it's cheaper.

      What do you guys think?

      EDIT: Got a Magicforce 68 for $47. Thanks for the help!

      9 votes
    6. To clarify I'm not incompetent at computers, I'm sure people don't tend to install Linux if they aren't familiar with technology in a decent capacity. But for instance I can't code, can't operate...

      To clarify I'm not incompetent at computers, I'm sure people don't tend to install Linux if they aren't familiar with technology in a decent capacity. But for instance I can't code, can't operate the command line short of copying and pasting command, and don't really know what I'm doing with the technical aspect other than following online guides. I have used windows all my life. I'm Linux illiterate for lack of a better description.

      I decided I wanted some form of USB bootable computer, i'm familiar with chrome books, enjoy the light weight OS, and am bed bound to the google ecosystem so I when I saw how you could plug in a USB and have the computer boot into Chrome OS running off the USB I thought that sounded perfect. But during my research of discovery I found that Linux seemed like a very good alternative, I had always had it in my head that it was very technical and finicky system where to do a simple google search you had to code in half a dozen lines into the control terminal in some bizarre 2018 text adventure to use the web, I do exaggerate of course but the image I had conjured up over the years was of a very non-user friendly experience and a system made for those running technical aspects such as web servers and system management.

      I decided you can't knock it to you try it and besides turns out you can't get chrome OS on a 32GB USB it has to be 8GB or 16GB apparently. So I installed Ubuntu on my USB, no clue if this is some snooty distro, or a version of Linux that's mocked in the community, or the perfect distro but after minimal research it seemed the most popular and well received version to put it on a USB and booted into it.

      Instantly all my preconceived notions we're erased. It's clean, modern, simple, light weight, and easy to use with a very intuitive and familiar UI. It's pretty much a more open and degooglified (That's a nice word) version of Chrome OS. Since Firefox Quantum was released I emigrated over to try break some ties with google for privacy reasons like it's some pervy conjoined twin of mine, I know it's not good for me, I don't want it there but I can't get rid of it without harming me.

      It's got a simple UI that's familiar to windows albeit without all the bloatware and ads spread everywhere, it doesn't track you like window does (that's as far as I'm aware it did ask to collect anonymised telemetry data which I opted out of). With windows I'm so used to having to go through 3 different pop up windows to change a setting that in Ubuntu it feels like I'm missing features although I'm yet to find one that's not there. The best bit about Linux, is if theirs a setting you want to change and can't find, than someone online has wrote a guide giving you a command line code to copy paste into the terminal to fix it.

      Although to me it feels more on par with Chrome OS than Windows as a bare bones OS with simple apps and a web browser to use the internet with, in this regard Linux wins easy, way more open, no profit based motivation, and more accessible allowing itself to be used anywhere.

      All though that comparison holds up for the normal user and if you are someone who just browses the web and uses apps like Spotify than Linux is amazing it's not complex or difficult, truly wonderful.

      What makes Linux even better is the fact it's not a fair comparison, sure to me it's like Chrome OS due to the simple purposes I use it for but what's truly great is all that nerdy technical stuff I thought Linux was for you can do, if you are hosting a web server than linux gives you a free platform to do it, it feels like you are directly modding the PCB of the computer it's that open.

      In retrospect to typing all that I feel I've just blurted out a generic description of Linux and for those that use it I'm sure they just think I was naive, but this is more aimed at the average user, Linux, or at least Ubuntu, is great, it's: simple, easy, fresh, clean, open, modern, intuitive, versatile, multi-purpose, and free. It's not some difficult to use system, it's alarmingly simple, but infinitely useful

      It's easy to learn and difficult to master.

      65 votes
    7. Pretty straight forward question, but basically I was watching a discussion panel the other day talking about the ethics of Self-Driving cars. A topic came up about people writing crappy code, and...

      Pretty straight forward question, but basically I was watching a discussion panel the other day talking about the ethics of Self-Driving cars. A topic came up about people writing crappy code, and more than that, people not testing their code. And if they do, they do point testing. I am in my last semester of uni and I am working with some companies where we are doing pretty extensive testing, happy flows and a lot of alternate flows, as well as UI/UX testing. I wanted to extend this question to you, do you guys do testing, what type? How much do you focus on it? And if u love it/hate it?

      13 votes
    8. So, the black installation doc tells me to install black by using: pip install black I don't know what pip is so I go read about it here. These instructions tell me that pip is already installed...

      So, the black installation doc tells me to install black by using: pip install black

      I don't know what pip is so I go read about it here. These instructions tell me that pip is already installed since I have the latest version of Python installed.

      That's wonderful, right?

      Not for me. How do I install black?

      Black can be installed by running pip install black.

      Do I run this from the Terminal (I'm using Mac)?

      5 votes
    9. Preface Conceptual models in programming are essential for being able to reason about problems. We see this through code all the time, with implementation details hidden away behind abstractions...

      Preface

      Conceptual models in programming are essential for being able to reason about problems. We see this through code all the time, with implementation details hidden away behind abstractions like functions and objects so that we can ignore the cumbersome details and focus only on the details that matter. Without these abstractions and conceptual models, we might find ourselves overwhelmed by the size and complexity of the problem we’re facing. Of these conceptual models, one of the most easily neglected is that of data and object structure.


      Data Types Galore

      Possibly one of the most overwhelming aspects of conceptualizing data and object structure is the sheer breadth of data types available. Depending on the programming language you’re working with, you may find that you have more than several dozens of object classes already defined as part of the language’s core; primitives like booleans, ints, unsigned ints, floats, doubles, longs, strings, chars, and possibly others; arrays that can contain any of the objects or primitives, and even other arrays; and several other data structures like queues, vectors, and mixed-type collections, among others.

      With so many types of data, it’s incredibly easy to lose track in a sea of type declarations and find yourself confused and unsure of where to go.


      Tree’s Company

      Let’s start by trying to make these data types a little less overwhelming. Rather than thinking strictly of types, let’s classify them. We can group all data types into one of three basic classifications:

      1. Objects, which contain key/value pairs. For example, an object property that stores a string.
      2. Arrays, which contain some arbitrary number of values.
      3. Primitives, which contain nothing. They’re simply a “flat” data value.

      We can also make a couple of additional notes. First, arrays and objects are very similar; both contain references to internal data, but the way that data is referenced differs. In particular, objects have named keys while arrays have numeric, zero-indexed keys. In a sense, arrays are a special case of objects where the keys are more strictly typed. From this, we can condense the classifications of objects and arrays into the more general “container” classification.

      With that in mind, we now have the following classifications:

      1. Containers.
      2. Primitives.

      We can now generally state that containers may contain other containers and primitives, and primitives may not contain anything. In other words, all data structures are a composition of containers and/or primitives, where containers may accept containers and/or primitives and primitives may not accept anything. More experienced programmers should notice something very familiar about this description--we’re basically describing a tree structure! Primitive types and empty containers act as the leaves in a tree, whereas objects and arrays act as the nodes.


      Trees Help You Breathe

      Okay, great. So what’s the big deal, anyway? We’ve now traded a bunch of concrete data types that we can actually think about and abstracted them away into this nebulous mess of containers and primitives. What do we get out of this?

      A common mistake many programmers make is planning their data types out from the very beginning. Rather than planning out an abstraction for their data and object architecture, it’s easy to immediately find yourself focusing too much on the concrete implementation details.

      Imagine, for example, modeling a user account for an online payment system. A common feature to include is the ability to store payment information for auto-pay, and payment methods typically take the form of some combination of credit/debit cards and bank accounts. If we focus on implementation details from the beginning, then we may find ourselves with something like this in a first iteration:

      UserAccount: {
          username: String,
          password: String,
          payment_methods: PaymentMethod[]
      }
      
      PaymentMethod: {
          account_name: String,
          account_type: Enum,
          account_holder: String,
          number: String,
          routing_number: String?,
          cvv: String?,
          expiration_date: DateString?
      }
      

      We then find ourselves realizing that PaymentMethod is an unnecessary mess of optional values and needing to refactor it. Odds are we would break it off immediately into separate account types and make a note that they both implement some interface. We may also find that, as a result, remodeling the PaymentMethod could result in the need to remodel the UserAccount. For more deeply nested data structures, a single change deeper within the structure could result in those changes cascading all the way to the top-level object. If we have multiple objects, then these changes could propagate to them as well. And what if we decide a type needs to be changed, like deciding that our expiration date needs to be some sort of date object? Or what if we decide that we want to modify our property names? We’re then stuck having to update these definitions as we go along. What if we decide that we don't want an interface for different payment method types after all and instead want separate collections for each type? Then including the interface consideration will have proven to be a waste of time. The end result is that before we’ve even touched a single line of code, we’ve already found ourselves stuck with a bunch of technical debt, and we’re only in our initial planning stages!

      To alleviate these kinds of problems, it’s far better to just ignore the implementation details. By doing so, we may find ourselves with something like this:

      UserAccount: {
          Username,
          Password,
          PaymentMethods
      }
      
      PaymentMethods: // TODO: Decide on this container’s structure.
      
      CardAccount: {
          AccountName,
          CardHolder,
          CardNumber,
          CVV,
          ExpirationDate,
          CardType
      }
      
      BankAccount: {
          AccountName,
          AccountNumber,
          RoutingNumber,
          AccountType
      }
      

      A few important notes about what we’ve just done here:

      1. We don’t specify any concrete data types.
      2. All fields within our models have the capacity to be either containers or primitives.
      3. We’re able to defer a model’s structural definition without affecting the pace of our planning.
      4. Any changes to a particular field type will automatically propagate in our structural definitions, making it trivial to create a definition like ExpirationDate: String and later change it to ExpirationDate: DateObject.
      5. The amount of information we need to think about is reduced down to the very bare minimum.
      6. By deferring the definition of the PaymentMethods structure, we find ourselves more inclined to focus on the more concrete payment method definitions from the very beginning, rather than trying to force them to be compatible through an interface.
      7. We focused only on data representation, ensuring that representation and implementation are both separate and can be handled differently if needed.

      SOLIDifying Our Conceptual Model

      In object-oriented programming (OOP), there’s a generally recommended set of principles to follow, represented by the acronym “SOLID”:

      • Single responsibility.
      • Open/closed.
      • Liskov substitution.
      • Interface segregation.
      • Dependency inversion.

      These “SOLID” principles were defined to help resolve common, recurring design problems and anti-patterns in OOP.

      Of particular note for us is the last one, the “dependency inversion” principle. The idea behind this principle is that implementation details should depend on abstractions, not the other way around. Our new conceptual model obeys the dependency inversion principle by prioritizing a focus on abstractions while leaving implementation details to the future class definitions that are based on our abstractions. By doing so, we limit the elements involved in our planning and problem-solving stages to only what is necessary.


      Final Thoughts

      The consequences of such a conceptual model extend well beyond simply planning out data and object structures. For example, if implemented as an actual programming or language construct, you could make the parsing of your data fairly simple. By implementing an object parser that performs reflection on some passed object, you can extract all of the publicly accessible object properties of the target object and the data contained therein. Thus, if your language doesn’t have a built-in JSON encoding function and no library yet exists, you could recursively traverse your data structure to generate the appropriate JSON with very little effort.

      Many of the most fundamental programming concepts, like data structures ultimately being nothing more than trees at their most abstract representation, are things we tend to take for granted and think very little about. By making ourselves conscious of these fundamental concepts, however, we can more effectively take advantage of them.

      Additionally, successful programmers typically solve a programming problem before they’ve ever written a single line of code. Whether or not they’re conscious of it, the tools they use to solve these problems effectively consist largely of the myriad conceptual models they’ve collected and developed over time, and the experience they’ve accumulated to determine which conceptual models need to be utilized to solve a particular problem.

      Even when you have a solid grasp of your programming fundamentals, you should always revisit them every now and then. Sometimes there are details that you may have missed or just couldn’t fully appreciate when you learned about them. This is something that I’m continually reminded of as I continue on in my own career growth, and I hope that I can continue passing these lessons on to others.

      As always, I'm absolutely open to feedback and questions!

      14 votes