Archive link: https://archive.ph/A7LI4

Marianne Belotti has worked at large institutions with modernizing decades-old code bases. She is author of the book "Kill it with Fire" [review].

From that book's author bio:

Marianne Bellotti has worked as a software engineer for over 15 years. She built data infrastructure for the United Nations to help humanitarian organizations share crisis data worldwide and tackled some of the oldest and most complicated computer systems in the world as part of United States Digital Service. At Auth0 she ran Platform Services, a portfolio that included shared services, untrusted code execution, and developer tools. Currently she runs Identity and Access Control at Rebellion Defense. She can be found on most social networks under the handle bellmar.

Cody, one of the first few decently good AI assistants that were well integrated into VSCode bit the dust just recently as the greedier and greedier Sourcegraph direction decided to switch to the completely Enterprise (read proprietary) "solution" Amp.

With this commit, another notable project by them goes down, first was their signature code search engine, now this, I just feel sorry for everybody who contributed and now will see pretty much all their efforts rendered meaningless, it was already apparent by how Sourcegraph approached Search sunsetting how much they care about open source, but I'd say this seals the deal even better if you needed insight into whether to trust them or not.

I think what's left by them that might be useful still is the zoekt library and a few other minor repos they have, but they're nothing compared to the impact of the other two.

Things like these make me question how we can just buy in to projects using non-copyleft licences, it's a time bomb, especially with corporate driven software and I see many developers fall into that trap, that in an endeavour for perceived simplicity, will choose Apache, MIT, Unlicense (pls not this one 🥲), or what have you and not care.
What people see as pragmatic in open source is really just a conclusion that comes from the point of view of the maker, rather than the community

Cool even if you're not interested in learning Scheme. It has some neat features.

Code as data? 😵‍💫

I thought of this recently (anti llm content within)

The reason a lot of companies/people are obsessed with llms and the like, is that it can solve some of their problems (so they think). The thing I noticed, is a LOT of the things they try to force the LLM to fix, could be solved with relatively simple programming.

Things like better searches (seo destroyed this by design, and kagi is about the only usable search engine with easy access), organization (use a database), document management, etc.

People dont fully understand how it all works, so they try to shoehorn the llm to do the work for them (poorly), while learning nothing of value.

A bit old but still interesting

Not yet released unfortunately:

https://kyber.media/

So, I work in a medium sized team and earlier in this year, our team helped another that was behind in some tasks that all of us need to complete together.

After this, that team always asks for help from our team for untested things from their side and the worst part is whenever something breaks on their side, it breaks for a lot of people (like us) too, and they break a lot of stuff, simply not testing anything, no unit tests, no integration tests, nothing, they just throw broken shit out of the door.

This happens even to the things we made at their place, something's up with our code? They changed it. It doesn't seem to matter if it's adding 2 lines to a sql query, they added an extra comma and didn't test, they changed the batch processing? Now the process returns a broken json with different fields than the Enum expects. Yeah, they changed the value of the field that was ALREADY working for no reason and didn't test it.

I'm pissed off, told my coworker that it's their problem now, but the problems always come and the boss call us to help. This is very frustrating for us and for other teams too, even today another boss was talking about them breaking things in another system that we and they interact.

Their boss seemed to just want to give work for them, even with these problems coming back. The outsourced people work better than them, but you know, they are outsourced and the not so competent team is in house, so they can do nothing.

What can I do? Just saying no when the problems come? Talking to their boss?

An oldy but a goody.

I'm currently writing a CLI tool that handles a specific JSON data format. And I also want to give the user to get a slice of the item array of the file. It's a slice in form of --slice START:END through commandline options. So in example --slice 1:2.

1. Should I provide a 0 based index for the access or a 1 based index? In example --slice 1:2 with 0 based index would start with the second element and with 1 based index it would start with the first element.
2. And would you think its better to have the END to be inclusive or exclusive? In example --slice 1:2 would get only one element if its exclusive or it gets two elements if its inclusive.

I know this is all personal taste, but I'm currently just torn between all options and cannot decide. And thought to ask you what you think. Maybe that helps me sorting my own thoughts a bit. Thanks in advance.

Im 19 and for years my mother has been telling me to use codecademy but most of its locked behind a paywall. Have any of you used this site, what are your thoughts on it? Are there better totally free alternatives that walk you thru everything?

Someday i want to make games or something like that but im unsure what programming language to choose. I like the look of lua but im not sure if i should go with it or what projects to learn from? Everyone here tells me if i i choose to go with gamedev someday, to pick up godot but i feel im not ready to make games and that i need to start learning the basics.

cross-posted from: https://gregtech.eu/post/16416819

Hi, what's the best way for testing a gin route?

I currently have one function where the routes are defined. Here it is:

package router

import (
	"github.com/gin-gonic/gin"
	"github.com/gragorther/epigo/handlers"
	"github.com/gragorther/epigo/middlewares"
)

func Setup(userUserStore handlers.UserUserStore, groupGroupStore handlers.GroupGroupStore, groupAuthStore handlers.GroupAuthStore, messageAuthStore handlers.MessageAuthStore, messageMessageStore handlers.MessageMessageStore, middlewareUserStore middlewares.UserStore) *gin.Engine {
	r := gin.Default()
	r.Use(middlewares.ErrorHandler())

	userHandler := handlers.NewUserHandler(userUserStore)
	authHandler := middlewares.NewAuthMiddleware(middlewareUserStore)
	groupHandler := handlers.NewGroupHandler(groupGroupStore, groupAuthStore)
	messageHandler := handlers.NewMessageHandler(messageMessageStore, messageAuthStore)

	// user stuff
	r.POST("/user/register", userHandler.RegisterUser)
	r.POST("/user/login", userHandler.LoginUser)
	r.GET("/user/profile", authHandler.CheckAuth, userHandler.GetUserProfile)
	r.PUT("/user/setEmailInterval", authHandler.CheckAuth, userHandler.SetEmailInterval)

	// groups
	r.DELETE("/user/groups/delete/:id", authHandler.CheckAuth, groupHandler.DeleteGroup)
	r.POST("/user/groups/add", authHandler.CheckAuth, groupHandler.AddGroup)
	r.GET("/user/groups", authHandler.CheckAuth, groupHandler.ListGroups) // list groups
	r.PATCH("/user/groups/edit/:id", authHandler.CheckAuth, groupHandler.EditGroup)

	// lastMessages
	r.POST("/user/lastMessages/add", authHandler.CheckAuth, messageHandler.AddLastMessage)
	r.GET("/user/lastMessages", authHandler.CheckAuth, messageHandler.ListLastMessages)
	r.PATCH("/user/lastMessages/edit/:id", authHandler.CheckAuth, messageHandler.EditLastMessage)
	r.DELETE("/user/lastMessages/delete/:id", authHandler.CheckAuth, messageHandler.DeleteLastMessage)
	return r
}

so, my question is, how can I test just one route? should I run this function in every test and send a request to a route with httptest? Or should I set up my handlers like it's described at https://gin-gonic.com/en/docs/testing/

(like this)

func postUser(router *gin.Engine) *gin.Engine {
  router.POST("/user/add", func(c *gin.Context) {
    var user User
    c.BindJSON(&user)
    c.JSON(200, user)
  })
  return router
}

let me know if you have any other questions about my code.

It's available on github: https://github.com/gragorther/epigo

cross-posted from: https://lemmy.today/post/34279957

guix shell sees to it that all of the dependencies (listed in the inputs and native-inputs sections) are available within the shell session it creates by downloading (or building, if necessary) the entire dependency tree.

Should you want/need more isolation from the host system, guix shell has you covered. The --pure flag will clear out most existing environments variables, such as $PATH, so that the resulting environment does not contain pointers to places like /usr. For more Docker-like isolation, the --container flag can be used, which will run the new shell session within a set of Linux namespaces so that the host system is inaccessible.

I’ve been working on this (not so little anymore) project for some time now, and I’m finally happy with the branding, UX and docs state.

It’s a scripting language I made at first as a toy, to learn new parsing methods, explore compiler optimizations, and go back to VM land where everything is low level and amazing (at least for me) ; it’s now a fully fledged language that can be used as a scripting language like Python or Ruby, and can also be very easily embedded inside a project, as one would do with Lua.

Let me know your thoughts and opinions on the project!

Decentralized Architecture: https://positive-intentions.com/blog/decentralised-architecture

While my approach here could be considered overly complicated (because, well, it is), I'm trying something new, and it's entirely possible this strategy won't be viable long-term. My philosophy is "there's only one way to find out." I'm not necessarily recommending this approach, just sharing my journey and what I'm doing.

Potential Benefits

I've identified some interesting benefits to this approach:

• Statics as Chat App Infrastructure: https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure

While I often see module federation and microfrontends discouraged in online discussions, I believe they're a good fit for my specific approach. I'm optimistic about the benefits and wanted to share the details.

When serving the federated modules, I can also host the Storybook statics. I think this could be an excellent way to document the modules in isolation.

Modules and Applications

Here are some examples of the modules and how they're being used:

• Cryptography Modules: https://cryptography.positive-intentions.com/?path=%2Fdocs%2Fcryptography-introduction--docs
• P2P Framework: https://p2p.positive-intentions.com/?path=%2Fdocs%2Fe2e-tests-connectionstatus--docs

This setup allows me to create microfrontends that consume these modules, enabling me to share functionality between different applications. The following applications, which have distinct codebases (and a distinction between open and closed source), would be able to leverage this:

• P2P Chat: https://chat.positive-intentions.com/
• P2P File Transfer: https://file.positive-intentions.com/

Sharing these dependencies should make it easier to roll out updates to core mechanics across these diverse applications.

Furthermore, this functionality also works when I create an Android build with Tauri. This could streamline the process of creating new applications that utilize these established modules.

Considerations and Future

I'm sure there will be some distinct testing and maintenance overhead with this architecture. However, depending on how it's implemented, I believe it could work and make it easier to improve upon the current functionality.

It's important to note that everything about this project is far from finished. Some might view this as an overly complicated way to achieve what npm already does. However, I think this approach offers greater flexibility by allowing for the separation of open and closed-source code for the web. Of course, being JavaScript, the "source code" will always be accessible, especially in the age of AI where reverse-engineering is more possible than ever before.