basically you make an onion, where the core domain logic handles well, your actual logic the adapter handles requests and makes them understandable for your core part the port part is your db or anything like that, it's usually an implementation of an interface
While I’m not a lawyer, the MIT license is very short. It very clearly states that the MIT license shall be included in any projects that include copies or substantial portions of the MIT-licensed source code. As a result, any projects that are modifications/forks of an MIT-licensed project are, inherently, forced to have the MIT license included with them.
Or in short: You can’t take an MIT licensed project, modify it, and remove the MIT license because of your modifications.
As such, 2xx04 is technically in violation of the MIT license. The main thing I don’t know is whether that gives you the right to treat 2xx04’s repository as though it is MIT license. However, you forked the original project, which means 2xx04 is directly referenced by your repository. To be honest, unless I intended to make money off such a project … I wouldn’t sweat it too hard.
I don’t know if they removed the license strictly speaking, they replaced it with a link to the upstream license, which seems fine to me on a surface level.
Ah, that honestly works fine in my book. It’s a bit opaque, but it at least appears that 2xx04 acknowledges the existence of those licenses, which I’d imagine is good enough proof not to get in trouble somehow by forking it!
My AOP Professor once said that today, we build software like medival smiths built swords: The customer would describe how he would want his sword to look and feel like, and the smith crafted each and every one individually. This led to very unique and well fit, but also very expensive products.
He said that we should aim to build software products like the industrialization revolutionalised manufacturing: Assembling many modular parts into something, instead of hand crafting everything. In his opinion, this will lead to faster and cheaper development.
Sort of. I think of the Unix philosophy as being like Lego. Here’s a box of goodies, go crazy. Even Ikea still requires user assembly.
Most end users just can’t do much with the first and often even get tripped up by the second. What we need is something in between that a programmer can use to quickly throw something together to user requirements.
Actually, that’s much like what I was doing with Microsoft Access and Visual Basic decades ago. I probably would never have survived in an actual software development shop, but I was kept very busy by a bunch of small businesses that loved the quick turnaround and manageable costs.
+1 for Lazygit. It doesn’t cover all of my needs so I have to use the CLI for a few small things, but for 99% of your typical git usage this tool is such a gift.
I started as a sysadmin in 1995 and started programming not long after that. I spent most my time in a shell and vim, started writing python all in vim. Then I took on a project that was a graphical application for windows and OS X. It was a rewrite of a windows visual basic app that we did not have the source for, so now good opportunity to write a multi platform application.
I wrote that program in python/pyQt3. Started on linux (which it also ran on) decided to look at IDE’s to help with pyQt I found Eric3. It made writing the first app and many after a lot easier.
So moved on from there a few years later and I use Jetbrains Pycharm commercial if I am writing anything bigger then a quick script I will do it in Pycharm.
Some of the things I like in Pycharm.
really good vim emulation
the linter finds code problems very well
completion is great
debugger is fantastic I rarely use a print to debug but it still happens
Increase’s productivity, hard to see at first.
I strongly recommend looking at IDE’s start with Kdev and see where it goes also try the trial version of Jetbrains Clion. www.jetbrains.com/clion/
It feels like a lot of extra work to learn an IDE but it pays in productivity. Watch some videos on Clion.
Another way to develop would be through iterating within a Unit Test that you don’t plan to keep around.
Uh, I set a breakpoint and run the app?
To add a bit more context, it’s more difficult to configure a debugger when the application is running within something like Docker. How difficult? That depends on the language and tools you’re using.
I’ve seen the fun of “prints everywhere” in production when a colleague forgot to remove a “Why the fuck do you end up here?” followed by a bunch of variables before committing a hot-fix… Customers weren’t to amused…
Edit: That was a PHP driven web shop and the message ended up on to of the checkout page
I’ve used a debuggers only a handful of times in the last decade or so. The projects I work on have complex stacks, are distributed, etc. The effort to get that to run in a debugger is simply not worth it, logging and testing will do 99.9% of the time. Profiling on the other hand, now that’s useful, especially on prod or under prod load.
We have so many debug logs that trying to find your log of a background takes a non zero amount of time.
So just inserting system(“xeyes”); is actually way easier, to get instant feedback, and you can just use system(“xmessage msg”), if you need a message.
programming
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.