I have a server app in C; I need to keep track of a vast number of sockets simultaneously (client session data). I don't want to reinvent the wheel and just saw that GLib comes with a hash table implementation. Can a GLib hash table safely be used for what I want to do? Is there anything I should be aware of? Thanks!
I use GHashTable a lot, both with provided and custom equal/hashing functions, and have nothing but praise for it. Lean and fast implementation with very little overhead. The flexibility it offers in grabbing all keys and/or values as separate GLists, and providing custom free-functions for them is also very useful. Go for it.
Related
I realise that property lists are a way to store relatively small amounts of data in a structured way and see clearly what a row in a list is composed of, so they might, for example, be used for table data to avoid hard coding long arrays or dictionaries. Just wondering what other uses they have for developers outside of this? I know they are used for configuration files created by Apple also. Just wondering are they worth learning too much more about. Are they employed much by iOSdevelopers out there and if so, when?
Edit: When to use over NSKeyedArchiver, NSUserDefaults, etc.? Just curious about when they are best taken off the shelf for use. Don't want to be using them for the sake of it. Like at a maximum of how many items in an array would you starting considering to use a plist?
I have become a great fan of the powerful type system in F# and how it allows you to create some very tight restraints on your domain models (for those interested, see this). I have also become a great fan of RavenDB and how it makes database work very simple in most of the cases I run into. However, there seems to be issues getting the two to play nicely together - at least if you insist on immutable types.
As long as you don't ever have to update your entities, all you need to do is make the id property mutable. While I'm certainly not happy that this is necessary, I can live with it. However, it seems that change tracking is handled in such a way that you must mutate the original object retrieved from the database and it is not possible to attach a new object to the database to represent an updated version of an existing entity. It does seem to be possible to do what I want using the patching API, but the documentation clearly warns against this type of general usage.
Am I missing a part of the RavenDB API that will let me do this without too much fuss or must I abandon the idea of immutable domain models (or perhaps make a feature request for it)?
The problem with immutable in that scenario is that you are actually dealing with mutable data.
The document is being mutated. The fact that you don't mutate it in user space is of little matter here.
What you can do is wrap calls to Advanced.Evict & Store in a StoreUpdated or something like that extension method. But I would call into question the usage of immutable data to represent mutable state.
I'm programming the backend of a mobile application and I've come across this problem, wondering whether I can use a rails tool or should I implement a new technology to my current system.
We have our user that is able to make a request, demanding to chat anyone who is around. However our system (the backend) has to collect this data and choose one of users who agree to chat randomly. But for that I want to keep all the ones that agree to chat in a list and pick one element randomly. But I would like to implement this in a volatile way so that when someone random selected all the other candidates will be gone.
Of course, those candidates could be easily stored in a table and later on could be deleted but I believe that there is a structure that I can use on demand and dump whenever I want. So what kind of data structure I should use to provide this efficiency?
If you want a volatile storage option for this, Redis is probably the best choice. Since data is stored in memory, it is fast. If you have many Rails instances running, they will still access the same central Redis server.
If you want to know a data-structure for this, I guess an array of user id is enough.
I have a postgresql database which contains multidimensional data. What I did was I wrote a data structure that sorts all database rows into a tree format. Now the database is large and so I dont want to generate the tree every time a request comes in from a browser. What Id like to do is construct the tree once in a certain time period and persist it in memory on the server.
The tree is read only by the way. So now each time a request comes in the tree need not be generated new, its already there.
How can I make this happen. Im not an expert programmer, just a beginner and definitely new to web programming. So some of these concepts are new to me.
But if you could please point me in the right direction in terms of the concepts involved here, I can google the rest.
Or if you have actual links or examples that would be fantastic.
Thanks
There are several ways to approach this problem. It depends on just how close to the application you want the variables. If you're really looking to have them right "on top" of the application, for fastest possible use, then you could look at using a global variable "$tree" and hooking in to the application flow. Other options might include memcached, which is still pretty darn close to the application. Redis would be a good option for an in-memory database that could be shared between instances of an application, as it is a NoSQL database that you query. Not quite as close to the application though.
Generally, those are your primary options. In-application variables that survive requests. Application frameworks that will help variables survive requests and provide you a querying mechanism. Or, an In-Memory databases that will allow you to store and query rapidly from multiple instances. Each is a viable option, though I'm pretty sure you'd get a lot of 'community' flack for using a straight up global variable (such practices are considered unclean for their lack of thread-safety and other such concerns).
I come from a mostly n-tier background, and I'm trying to move more towards a DDD architecture. I'm trying to find best practices for designing the application service, and after a few searches, am still left with a few questions. Granted, I know I can't be the first person to ask these questions, so if you know where these are answered, just point me the way and I'll happily close this.
Here are my main questions:
How "open" should your signatures be? For example, is it better to be more rigid with your signatures and use simple types as parameters when possible, or is it better to use objects (messages?) that can later be modified without breaking the signature?
If you want to expose variations of a signature, for example, a UserSearch method that returns a list of users based on various (and sometimes optional) search criteria, is it better to:
A. Use overloads
B. Use optional (or nullable) parameters
C. Break each scenario into its own unique method
D. Use messages
I know that some of these answers are subjective, and also depend on what all will be calling your application service. But I'm just trying to get a general direction of things to consider and other best practices at this point.
Thanks in advance.
Good questions. Thinking about the API is obviously important.
1) How open would depend for me would depend on who the consumers are. If this application service is only being used within the context of your own solution and/or team then I think it's fine to have specific messages (or rather their interfaces) or Dtos (data transfer objects). Though if as easy then keeping to simple types is best in my book and definitely better if being consumed by others. If they don't suffice then interfaced messages that provide only just enough. Again if you are going to be distributed to different platforms then simple messages of simple types is not a bad way to go.
2) Why not have a SearchCriteria object as a paramater? It could be a SearchCriteria message of simple types if you are looking at this as a start of a messaging bus.
As you say, your question is a little open but I'd be interested to hear more as it sounds like you are asking the right questions at least.
Jerad, those are tough questions to answer generally, as you noted.
My personal preference is to use primitives in method signatures where possible. If I need to pass 3+ primitives to a method, I define custom data transfer objects.
The thinking being: if multiple values are being passed together, it's likely they represent a concept in your problem space, and thus should become an object. For example, if you are passing X and Y coordinates to a method, I'd recommend creating a Point class or struct that represents that concept.
The only time I'd end up with variations on a signature, it would be to provide convenience methods that provide default values for method parameters. To continue the above example, a Draw method might not require a Point, in which case I'd use (0,0).
So, I'd answer #1 with "not very open" and #2 with A.
I hope that helps.