programming

158 readers
14 users here now

  1. Post about programming, interesting repos, learning to program, etc. Let's try to keep free software posts in the c/libre comm unless the post is about the programming/is to the repo.

  2. Do not doxx yourself by posting a repo that is yours and in any way leads to your personally identifying information. Use reports if necessary to alert mods to a potential doxxing.

  3. Be kind, keep struggle sessions focused on the topic of programming.

founded 11 months ago
MODERATORS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 

Hi, I need to read handwriting off scanned documents and then file them digitally. What's the best way to approach this? I've done some searching myself but I'm curious what you nerds think. Ty.

15
16
17
18
 
 

Pretty much what is says in the title. Redis had been using the BSD-3 license for years to encourage developers to write code for them for free and now they've gone and switched to some custom proprietary license in order to secure their theft of the labor of everyone who has contributed to the project over the years. It's the same age old story.

A harsh, but important reminder to never write code for projects with these weak open source licenses. These licenses ONLY exist so that your labor can be stolen, either by them re-licensing at some point in the future or other companies taking it right now. That's the only reason they use BSD/MIT-style licenses.

As an aside it's a shame we're stuck with the GPL given the person who wrote it.

19
20
21
 
 

I'm building a system where I'll have some embedded devices sending audio data to my server via HTTP, along with a small amount of numerical data. It's important that before these are sent to the database, they're bundled together. Another point, the client needs to authenticate to upload data.

The naive solution would be to send everything together as a JSON object and just base 64 encode the audio, with a single backend endpoint for receiving both the audio and the other data. My concern is, base64 adds a pretty significant amount of overhead (4 bytes of base64 for every 3 bytes of audio) and that is a problem for me, it's more power usage and it's a medium amount of data, a 33% tax is non-trivial. Network encoding might reduce that problem, but I can't be entirely sure until I test.

The other solution would be setting up a different endpoint for audio that can receive the binary data directly, maybe through a stream. This probably is the most efficient way to go about it, but it introduces some complexity as to how I'm supposed to match up the audio with the other data. I'm not very familiar with backend engineering so I'm not sure if there's a straightforward solution that is just an unknown unknown for me.

Maybe I can hash the audio data in the client, include it in the header for both requests, then keep a record of incoming requests along with their hashes in a dictionary in the server (push them as they're received) so they can efficiently be matched up with each other? three-heads-thinking Feels like a cool solution, but IDK, thoughts? Should I just eat the 33% overhead from the simple solution and accept that premature optimization is the root of all evil?

22
23
1
So you think you know C? (wordsandbuttons.online)
submitted 10 months ago by [email protected] to c/[email protected]
24
25
view more: next ›