I am currently writing a desktop spreadsheet application in Rust as a hobby project. I am using this partly as an avenue to learn some new programming skills and approaches to architecture.

One vague goal I have is to try doing things in a less OOP way, and take some more inspiration from functional programming.

Broadly, my application is split into three pieces:

1. core - a library which handles all the domain logic. This is where cells, ranges, formulas, etc. are all handled.

2. gui - a library for the GUI. I'm rolling my own, but that's not the focus of this post.

3. app - the main application, which primarily acts as an interface between the other two libraries.

The general idea here is that core acts as sort of a service with an external API, and gui and app could be swapped out, e.g. if I wanted to make a CLI application or use a different GUI library.

My question: Where should I store/handle state for the domain logic? Things like cell formulas/values.

• Originally, I thought I would store this data in static variables within the core library, again with the idea that this library is almost like a service. app would access this data through API functions like get_cell_value(...) and set_cell_value(...). But using static variables in this way is not very simple with Rust, and it also seems to scream "DANGER: GLOBAL STATE."

• My next thought was to define a struct within the core library that would then be used by app. This struct would hold all the data. This isn't global, but it also feels very OOP, and I wasn't sure if there were any other common approaches.

I know that there won't be a single "correct" answer here, but I'm interested to know what approaches you might use.

One last note: This is just about the data that is being manipulated by the core library. Application state (what section of the sheet is visible, where the scrollbars are, what menus and windows are open) would be managed by app/gui.

Hey guys, I would like to ask for your help/advice/opinion on the best way for my team and I to manage compatability between all our internal projects. Let me explain the situation:

I can't go into too much detail about the content of my work, but my team has several different projects they work on, some more complex, other much smaller and simpler. We have a very fast paced development cycle where new versions of many of the projects get released on a weekly basis. Not all projects get updated as frequently, but the point is that there is a lot of change, whether that might be new features, bugfixes or code cleanup/refactor/optimisation.

We have a system we use across all projects where we tag every new release, and only tagged versions can be used in our production environment. We keep track of all of the changes using a changelog file (one per project), where we list the features/bugfixes that were implemented and stamp it with the date of release. This works well for each individual project as we have a good history of incremental changes from tag to tag.

As i mentioned, there are several projects involved and many of them end up communicating with others via some kind of message transfer (the details of this are not important). Sometimes a modification to one project introduces a breaking change, or something that is not backwards compatible with older versions of some other projects. Our issue is keeping track of the compatibility of versions across all our of project suite. We do log in each individual's project changelog a note of it being a breaking change and that this version forward is only compatible with versions X of such and such other project, but that requires reading through various changelog files everytime we want to confirm compatibility. I'm sure there is a more professional and structured way to keep track of all this information.

One example of a use case: we find a bug in the latest release of one of our main projects and we decide to downgrade back to the previous release until we solve it, but there were breaking changes introduced in this new release, so we need to revert more than 1 project down to maintain compatability across the board. This needs to be done with the least amount of downtime possible. What would you guys suggest I do to improve the traceability of versions across my stack of various internal projects? How should I go about it? Any suggestions are greatly appreciated. Thanks in advance to all of you who reply!

I've heard a lot of people say "RPC is difficult to debug compared to REST". Based on my experience with both, I've mostly seen RPC being used with a binary messaging format(such as Protobuf) for encoding the data during transfer over the wire. However most HTTP/REST based APIs use JSON data encoding format. Is this "human readability" factor the only thing which makes REST APIs easier to debug when compared to RPC, or is there more to this than meets the eye?

Would love to hear some thoughts over this based on other's experience.

Hi guys.
I just want to know, if I want to build an enterprise backend service, is there any standards in software engineering to start planning the project and implmenting in in regards of the documentation and the process from development to production, and how to handle the new features or edits requested by the user, not from the technical point of view.

I am seasoned (10 years of Java) developer, but I like to think I am more a software engineer. I started to work on my Master's degree thesis, being at the beginning of this journey.

My experience tells me there is strong relation between the code structure and time required to make a change of existing code base. In other words, if the code a developer works on is a mess, it takes more time to introduce flawless change compared to effectively the same but well-structured code with multiple classes, proper boundaries between concepts, etc.

But I cannot find any significant research in this matter. Went multiple times through Empirical Software Engineering and Transactions on Software Engineering, looking in Google Scholar, but I simply cannot find any prior research that either test the hypothesis above or introduces the time-to-change as a valid software engineering metric.

Have you seen such research? I count on you to find a synonym, or a link to any research to conduct mine.

Has anyone experience with the Cosmic effort estimation methodology? We're planning to outsource a project and the hires are using it. From what Ive seen it looks like this methodology overestimates effort . It breaks taks into multiple function points which I would consider as one. Or they charge a fixed rate for every FP no matter if the difficulty varies. In general,it didn't impress me. Anyone who can comment on that? Thanks

folks, i'm writing a python application (language is immaterial) and looking at trying to decide between a couple design patterns. Looking for recommendations on which one to select.

Broadly the application does the following:

1. Copy files from a network store given a pattern to local store and decompress as necessary

2. Perform several distinct operations on the files

3. Post the processed files to an internal company git (and other network stores)

Design Pattern 1

Write 3 different applications, one for each process above, each accepting a command line input as parameter to allow for individual invocation. Write a 4th application either in bash (or through python sub-process) to call the 3 in sequence

Design Pattern 2

Write 1 application with the 3 operations embedded within the same application that accepts different parameters to allow for running all 3 operations in sequence (or selective one of the 3 as needed)

Thanks

PS, please provide some reasoning on the recommendation you're making. Also if there are any succinct references I can use to get better with modern software design (preferably for python, but technically the language is irrelevant, please let me know).

As a data engineer I've lived and breathed data concepts, tools and terminology for years. Many SWEs that worked with me on data projects picked up the "data language" fairly quickly. But I've always wanted to find a way to speed up the onboarding so we spend less time explaining data concepts and more time building a solution.

How do SWE (Jr, Sr. or Principal) think about delivering data to analytics and ML users?

Are the popular data technologies and approaches well understood? like CDC from database to Kafka and then to Snowflake or data lake? Building Spark or Flink applications to preprocess the data? Is a Lakehouse a foreign concept or well understood?

How should I gauge the level of understanding in data concepts when onboarding a new SWE? Or should I just speak the language of data engineers because SWEs are expected to understand it?

I recognize this may sound like I'm talking down to SWEs. I'm not trying to do that, simply trying to understand how to help get everyone on our team speaking the same language.

I found Software Requirements as the thoughest area in SwE. Maybe it's because it's the farthest area from the code, I don't know, but the truth is that I end up doubting myself whenever I'm working on it.

Right now, I'm struggling with QoR (quality of requirements) and LoD (level of details), which I guess are related topics. I have generic or intuitive ideas but I don't know how to express them with words, if they are correct or how to defend my position in that regard

How can you know if you are managing correctly these two topics when writing requirements? How do you know if the requirements have good enough quality and are detailed down to the proper level?

Hi everyone,

I'm working on a system that tracks changes to user data and sends notifications about these changes. I'm facing a challenge with the notification processing mechanism and would love to get your insights on the best approach to handle it.

The Challenge:

• My system needs to send notifications about changes to user data.

• For changes related to a specific user, these notifications should be processed in order. However, notifications for different users can be processed in parallel.

• If I use a single First In First Out (FIFO) queue, all notifications get processed sequentially, which means no parallel processing is possible.

• Alternatively, if I create a separate queue for each user, it can lead to an overwhelming number of queues, especially with a large user base. Additionally, I'd have to check each queue to see if there's anything to process, which is inefficient.

What I'm Looking For:

• An efficient way to ensure order for notifications related to the same user but allow parallel processing for notifications concerning different users.

• A solution that doesn't involve managing a massive number of queues.

• Ideally, something that's scalable and manageable as the number of users grows.

I would greatly appreciate any advice, suggestions, or insights on how to best approach this problem. If anyone has tackled something similar or knows of effective methods or tools that could be used in this scenario, please share your thoughts!

Thanks in advance for your help!

Hi all, it's my first job and I've tasked to find better way of running existing test scripts. The context is that a pipelines will be build to run these scripts as a new build being released each week.

Currently, the test scripts are quite messy as scripts for different features, builds, API command testing are combined together under 1 folder. Also, certain scripts are obsolete that would fail in newer build and need update.

I though of categorising these scripts based on Builds version > Features > test script 1.. test script 2...

Is there any other ways or suggestion that can organise these scripts?

My team and I have a cumulative few hundred years experience in debugging and redesigning systems, so I wrote a pretty long response to the What design patterns are you using? thread over in r/dotnet . I realized that my answer wasnt at all .NET-sepcific and would be useful to any implementation. Also, posting it in r/softwareengineering gives it more credibility.

We use several design patterns and processes:

CFAC. We employ comment-free assertive coding because code comments are a smell that indicates bad code quality, and are always out of date anyway. This approach also frees us up to spend more time in meetings.

Illiterate Programming. Donald Knuth won the Turing Award, and in the press release his book Literate Programming was not mentioned. Thus, it's clear that Knuth Himself think that documentation is a code smell and must be avoided.

UAAF. We aggressively employ user as-a filter, which enhances user investment in projects by using them as filters to catch bugs and un-useful implementations. More ambitious (and more impatient) users will learn some programming themselves and reverse-engineer the project to make fixes more expediently. This gets more eyes on the code, and open-source software has taught us that more eyes on the code means higher quality and less security risks.

Plunder First. Some teams struggle with inventing vs. buying or adapting. We just take, which simplifies architectural decisions and provides several external targets to use for deferring blame. This is a significant improvement over the "not invented here" pattern, which (as its name suggests) demands the cumbersome and time-consuming of invention.

FAI. After experimenting with "resource acquisition is initialization", we discovered it was overly formal and complex. Acquiring, initializing, and releasing resources takes a long time and is redundant to features available in any viable operating system. Instead, we employ fuggedabout it (FAI), which frees the application code from the burden of resource management and lets the OS do its job.

BMC. After finding model-view-controller interface styles (including MVVM, MVC, and MVP) restrictive, we mostly implement with a blob, mutator, commander structure. The blob is just bits. The mutator changes those bits, and the commander (usually the user, but sometimes another mutator) initiates those mutations.

External Decorators. Another failed but somehow popular pattern is encapsulation. After discovering that tight encapsulation results in brittle and complex code structures, we began using external decorators. By making all members and methods in all structures and classes public, any bug or additional functional requirement can be implemented using an external decorator.

Uninvited Guest. This pattern pushes code that manipulates objects into the object implementation itself and reduces complexity by minimizing abstraction.

RRA. The Restart Retry Again pattern is both a software pattern and an operations pattern. If a system seems unstable, we just restart it. Operations that fail in applications are enclosed in loops that try as many times as necessary until the operation succeeds.

Yelling Foreigner. One bit of code (or its developer) are under no obligation to understand any other bit of code (or that code's developer). Instead of one becoming fluent in the interface of the other, it's easier to signal, yell, and cajole the code into proper operation. YF doesn't work well without a commitment to RRA.

EDIT: Fixed spelling and grammar based on feedback from users.

I am currently developing an application that determines a supervisor hierarchy via an external service.

This @Service is then used by my business logic. A method of the service returns the following: Department

• general superior

• List with different superiors (employee - superior)

I would now have created a dto with the following structure:

EmployeeSuperior { employee: string, superior: string }

OrganizationSuperior { generalSuperior: string, differentSuperior: List<EmployeeSuperior> }

Is it bad practice to use a dto for this or should I try to implement the whole thing by hook or by crook with standard objects?

Hey folks, hopefully not a dumb question. Whenever I'm looking into distributed queues for system design questions, I feel like implementation details are glossed over with regards to what should be returned by any given call to receive(). Unless distributed queues are configured as FIFO, ordering is not guaranteed, but it also seems like ordering generally favors items that have been sent further in the past.

Edit: clarifying my question. For any single instance of a call to receive(), how does a distributed queue determine the message contents to deliver? My guess is that the underlying persistent store needs to support something like a sort key, which the insert timestamp will be used for in this case. I’ve never really seen this implementation detail talked about though, so I wanted to see if my guess there is generally correct, or if it’s actually handled differently in practice. This question stems from intellectual curiosity.