I wrote a JSON compiler and decompiler in October. After running a bunch of tests against other people's JSON, I was satisfied that it worked, and moved on. I mostly focused on the compiler, because that's usually the hard part, trying to understand all the variables that people can throw at you. JSON was, as advertised, pretty easy to work with (though not as easy, imho, as it could have been). No matter.
Now we've got a format that's starting to gain traction, a JSONification of stream of news displayed by River2. A bunch of Javascript devs are working on renderings of this data, some of which are now already nicer than the one I use, but none are yet functional enough for me to switch to.
But there's a problem with the JSON.
Each group of news bits is organized as a bunch of scalar data, like feed name, url, when the feed was last read, etc. Then there are one or more news items. If there's one item I just include a struct named item. If there's more than one I include a list of structs. The list is named item. I understood this is the convention for repeating elements in JSON.
http://scripting.com/images/2010/12/17/jsonShot.gif
In the screen shot above, there are two "updatedFeed" elements. The first has only one item, the second has more than one.
This causes problems for people in some languages because (apparently) it's hard for them to deal with an object without, in advance, knowing its type. So they say the solution is simple, always make it a list. Simple for them, but... :-)
But this is not so simple on my end. Because I'm using a generic JSON serializer, and it would have no way of knowing that "item" should always be a list. Unless...
One way of dealing with this (that I don't like and won't do) is to make everything a list.
I was just wondering what other JSON-producing environments do in situations like this.
JSON is a serialization format. It generally works best, if the same (expected) object has the same schema each time, or if the receiver is built to be flexible or ignore the parts that change.
In this case, it sounds to me that the news stream always should have the same format, so it sounds like you should tweak the object you are "compiling" to JSON, so that it always has the same structure, or use something like JSON Schema.
Related
I have a heavily nested JSON packet, containing arrays of arrays, and at the end of the chain there is invariably a key-value pair named: "id:" and "value:".
In the Power Automate interface, available objects, fields, etc are listed without any context so I just see a long list of "id" keys available without any indication, tooltip or other help to distinguish where they actually originate in the JSON structure.
At least, I haven't found a way to do this, so it is very frustrating just having to pick one at random, then "peek at code" to see if "by chance" I have picked correctly... which invariably I have not.
The PowerAutomate interface is SO frustrating for a tool that is so useful!
Does anyone out there know how to resolve this, or indeed, if it is not a problem, but I am doing it all wrong!?
Many thanks,
Currently we can't distinguish them(from the UI) indeed, we can just open the peek code as you mentioned. But the list of "id" keys should be sort by the order in your json data. You can feedback the problem in this page
I'm new to Immutable.js, so this is a very trivial question.
It looks like I can't get a Map value like with plain old Javascript objects, e.g. myMap.myKey. Apparently I have to write myMap.get('myKey')
I am very surprised by this behavior. Is there a reason for that? Is there any extension to Immutable.js which would allow me to type myMap.myKey?
Came back to elaborate on my comment, but SO doesn't allow that after certain time. Converting it into an answer.
The question you have asked has been reciprocated several times with people who start new with immutable, yours truly included. Its on one of the rants I wrote a while ago.
It starts to make sense when you look at it from immutability perspective. If you expose value types as your own properties, they won't be immutable because they are value types and could be assigned to.
Nonetheless, its frustrating to spread these getters all across your components/views. If you can afford it, you should try to use the Record type. It offers traditional access to members (except in IE 8). Better still, you can extend from this type and add helper getters/setters (e.g. user.getName(), user.setName('thebat') instead of user.get('name')/set('name', 'thebat')) to abstract your model's internal structure from your views. However there are challenges to overcome like nested structures and de-serialization of objects.
If the above is not your cup of tea, I'd recommend swallowing the bitter pill :).
I think you are missing the concept Immutable was build:
Immutable data cannot be changed once created, leading to much simpler
application development, no defensive copying, and enabling advanced
memoization and change detection techniques with simple logic.
Persistent data presents a mutative API which does not update the data
in-place, but instead always yields new updated data.
One way or another you may transform Immutable data structures to plain old JS objects as: myMap.toJS()
Spray-json-shapeless works fine for me for general cases. What I'm looking for is a way to extend the given functionality the output from enums in a special/customized way. Maybe there is an easy way how do do this. I'm new to all of this stuff and it is really hard for me to figure out.
At the moment I use a method similar to the spray ones, called enumFormat(enum). It contains the code for reading/writing JSON. It has to be specified for every enum, so I want to get rid of this.
It would be nice if it could work the same way as for case classes.
I have a class that contains a bunch of methods for checking data I scrape every week (for things like well-formedness and other errors in gathering the data). Each of these methods performs a test, and then prints out a summary of the test.
I want to print out the output from these tests to a file, but I'm not sure what the best way to do it is. For example...
Should the class hold an instance variable to the file, and each method open/appends/closes the file? (A problem is that methods sometimes call other methods, so this seems kinda messy?)
Should each method get passed the file as a parameter? (Seems messy as well.)
Should each method return a string, and a"central" method that calls all the other tests outputs all these strings to a file?
I'm not really familiar with using logger libraries -- would that be a solution?
My particular context
I have a scraper that pulls data from various websites and stores them in a database. Websites change all the time, so I'm writing a "scrape checker" program that checks my scrapes for various things, like:
number of empty results
length of results
weird characters in results
and so on
So I have methods like:
check_num_empty_results
check_weird_characters
check_scrape (calls a bunch of other checks)
check_scrape_pair (sometimes I want to check pairs of scrapes together, e.g., to match results against each other, so this is different checking each one in isolation)
etc.
I want my "scrape checker" program to print out a file that summarizes all the checks.
Separation of concerns. Write code the focuses on the scraping activity and return the value(s) scraped. Then use aspect oriented programming for logging, which can simplify the problem greatly as the aspect holds the reference to the file or logging API.
Ultimately, it depends on what language you're using.
The first solution makes the most sense if your language permits it. For each instance of the logging class, have a field for the file object that you're reading from/writing to. This is basically equivalent to passing the file object as a parameter to every method.
That said, most mature languages have modules that will do a lot of this work for you; off the top of my sh/awk, Perl, and Python all come to mind as being suited to this task (though if you want to, you could use Java or something else).
Seems like a logging framework would be a perfect solution for this. If you are using Java or .NET, log4j and log4net are pretty much the de-facto standards for that.
During coding I frequently encounter this situation:
I have several objects (ConcreteType1, ConcreteType2, ...) with the same base type AbstractType, which has abstract methods save and load . Each object can (and has to) save some specific kind of data, by overriding the save method.
I have a list of AbstractType objects which contains various ConcreteTypeX objects.
I walk the list and the save method for each object.
At this point I think it's a good OO design. (Or am I wrong?) The problems start when I want to reload the data:
Each object can load its own data, but I have to know the concrete type in advance, so I can instantiate the right ConcreteTypeX and call the load method. So the loading method has to know a great deal about the concrete types. I usually "solved" this problem by writing some kind of marker before calling save, which is used by the loader to determine the right ConcreteTypeX.
I always had/have a bad feeling about this. It feels like some kind of anti-pattern...
Are there better ways?
EDIT:
I'm sorry for the confusion, I re-wrote some of the text.
I'm aware of serialization and perhaps there is some next-to-perfect solution in Java/.NET/yourFavoriteLanguage, but I'm searching for a general solution, which might be better and more "OOP-ish" compared to my concept.
Is this either .NET or Java? If so, why aren't you using serialisation?
If you can't simply use serialization, then I would still definitely pull the object loading logic out of the base class. Your instinct is correct, leading you to correctly identify a code smell. The base class shouldn't need to change when you change or add derived classes.
The problem is, something has to load the data and instantiate those objects. This sounds like a job for the Abstract Factory pattern.
There are better ways, but let's take a step back and look at it conceptually. What are all objects doing? Loading and Saving. When you get the object from memory, you really don't to have to care whether it gets its information from a file, a database, or the windows registry. You just want the object loaded. That's important to remember because later on, your maintanence programmer will look at the LoadFromFile() method and wonder, "Why is it called that since it really doesn't load anything from a file?"
Secondly, you're running into the issue that we all run into, and it's based in dividing work. You want a level that handles getting data from a physical source; you want a level that manipulates this data, and you want a level that displays this data. This is the crux of N-Tier Development. I've linked to an article that discusses your problem in great detail, and details how to create a Data Access Layer to resolve your issue. There are also numerous code projects here and here.
If it's Java you seek, simply substitute 'java' for .NET and search for 'Java N-Tier development'. However, besides syntactical differences, the design structure is the same.