I am working on a project with a retard.
I am supposed to focus on the mobile apps but the backend guy doesn't know shit about REST.I spend more time teaching him how to serialize data into JSON and telling him not to store passwords as plaintext(He's now using md5 despite me telling him to use bcrypt) than developing the mobile apps am supposed to.
Guess who will be blamed for missing the deadline?
Yea, it's me.
Guess who will get the credits for the backend i am developing?
Yea, it's him.
Fuck!

So our method of complying with user removal requests for GDPR is:

audit.record("user {user.name} removed their account", serialize(user));

user.delete();

🤦

Developer came to our area to rant a bit about a problem he was having with Xamarin. A particular android device was receiving a java runtime error trying to de-serialize data from a WCF contract. What he found was not to use WCF and use WebAPI (or a simple REST service that sent back/forth JSON).

When he proposed changing the service (since the data transport didn’t really matter, he could plug the assembly into a WebAPI project in less than an hour), the dev manager shot down the idea pointing him to our service standard that explicitly stated no WebAPI (it’s in bold letters).

I showed him the date on the “standard”, which was 5 years ago. We have versioning on our sharepoint server, so I also him my proposal notes on the change request document (almost two years before that) stating we should stop using WCF in favor of REST based web standards. Dev manager at the time had wrote in his comment “Will never use REST. Enterprise developers prefer RPC.”
He just about fell over laughing when I showed him this gif.

A dev team has been spending the past couple of weeks working on a 'generic rule engine' to validate a marketing process. The “Buy 5, get 10% off” kind of promotions.

The UI has all the great bits, drop-downs, various data lookups, etc etc..

What the dev is storing the database is the actual string representation FieldA=“Buy 5, get 10% off” that is “built” from the UI.

Might be OK, but now they want to apply that string to an actual order. Extract ‘5’, the word ‘Buy’ to apply to the purchase quantity rule, ‘10%’ and the word ‘off’ to subtract from the total.

Dev asked me:

Dev: “How can I use reflection to parse the string and determine what are integers, decimals, and percents?”
Me: “That sounds complicated. Why would you do that?”
Dev: “It’s only a string. Parsing it was easy. First we need to know how to extract numbers and be able to compare them.”
Me: “I’ve seen the data structures, wouldn’t it be easier to serialize the objects to JSON and store the string in the database? When you deserialize, you won’t have to parse or do any kind of reflection. You should try to keep the rule behavior as simple as possible. Developing your own tokenizer that relies on reflection and hoping the UI doesn’t change isn’t going to be reliable.”
Dev: “Tokens!...yea…tokens…that’s what we want. I’ll come up with a tokenizing algorithm that can utilize recursion and reflection to extract all the comparable data structures.”
Me: “Wow…uh…no, don’t do that. The UI already has to map the data, just make it easy on yourself and serialize that object. It’s like one line of code to serialize and deserialize.”
Dev: “I don’t know…sounds like magic. Using tokens seems like the more straightforward O-O approach. Thanks anyway.”

I probably getting too old to keep up with these kids, I have no idea what the frack he was talking about. Not sure if they are too smart or I’m too stupid/lazy. Either way, I keeping my name as far away from that project as possible.

We don't know what one-to-many is! Instead, we convert all associated IDs to a string and join the list into a string separated by commas! Only after this absolute clownery do we save this new nice clean string to the database column! Then, when we want all associated entities, we serialize this list back into an array of IDs and retrieve them! It's clown-genius!

🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡

*Randomly using laptop to serialize data
*Only 8:53, already at 47%
*Checks bag for laptop cord
*Sees its not there
Oh god what have I done

So yeah XML is still not solved in year 2018. Or so did I realize the last days.
I use jackson to serialize generic data to JSON.

Now I also want to provide serialization to XML. Easy right? Jackson also provides XML serialization facitlity similar to JAXB.

Works out of the box (more or less). Wait what? *rubbing eyes*

<User>
<pk>234235</pk>
<groups typeCode="usergroup">
<pk>6356679041773291286</pk>
</groups>
<groups typeCode="usergroup">
<pk>1095682275514732543</pk>
</groups>
</User>

Why is my groups property (java.util.Set) rendered as two separate elements? Who the fuck every though this is the way to go?

So OK *reading the docs* there is a way to create a collection wrapper. That must be it, I thought ...

<User typeCode="user">
<pk>2540591810712846915</pk>
<groups>
<groups typeCode="usergroup">
<pk>6356679041773291286</pk>
</groups>
<groups typeCode="usergroup">
<pk>1095682275514732543</pk>
</groups>
</groups>
</User>

What the fuck is this now? This is still not right!!!

I know XML offers a lot of flexibility on how to represent your data. But this is just wrong ...

The only logical way to display that data is:
<User typeCode="user">
<pk>2540591810712846915</pk>
<groups>
<groupsEntry typeCode="usergroup">
<pk>6356679041773291286</pk>
</groupsEntry>
<groupsEntry typeCode="usergroup">
<pk>1095682275514732543</pk>
</groupsEntry>
</groups>
</User>

It would be better if the individual entries would be just called "group" but I guess implementing such a logic would be pretty hard (finding a singular of an arbitrary word?).

So yeah theres a way for that * implementing a custom collection serializer* ... wait is that really the way to go? I mean common, am I the only one who just whants this fucking shit just work as expected, with the least amount of suprise?
Why do I have to customize that ...

So ok it renders fine now ... *writes test for it+
FUCK FUCK FUCK. why can't jackson not deserialize it properly anymore? The two groups are just not being picked up anymore ...

SO WHY, WHY WHY are you guys over at jackson, JAXB and the like not able to implement that in the right manner. AND NOT THERE IS ONLY ONE RIGHT WAY TO DO IT!

*looks at an apple PLIST file* *scratches head* OK, gues I'll stick to the jackson defaults, at least it's not as broken as the fucking apple XML:

<plist version="1.0">
<dict>
<key>PayloadOrganization</key>
<string>Example Inc.</string>
<key>PayloadDisplayName</key>
<string>Profile Service</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist

I really wonder who at apple has this briliant idea ...

Conversation yesterday (senior dev and the mgr)..

SeniorDev: "Yea, I told Ken when using the service, pass the JSON string and serialize to their object. JSON eliminates the data contract mismatch errors they keep running into."
Mgr: "That sounds really familiar. Didn't we do this before?"
SeniorDev: "Hmmm...no. I doubt anyone has done this before."
Me: "Yea, our business tier processor handled transactions via XML. It allowed the client and server to process business objects regardless of platform. Partners using Perl,
clients using Delphi, website using .aspx, and our SQLServer broker even used it."
Mgr: "Oh yea...why did we stop using it?"
Me: "WCF. Remember, the new dev manager at the time and his team broke up the business processor into individual WCF services."
Mgr: "Boy, that was a crap fest. We're still fighting bugs from the mobile devices. Can't wait until we migrate everything to REST."
SeniorDev: "Yea, that was such a -bleep-ing joke."
Me: "You were on Jake's team at the time. You were the primary developer in the re-write process saying passing strings around wasn't the way true object-oriented developers write code.
So it's OK now because the string is in JSON format or because using a JSON string your idea?"

SeniorDev turns around in his desk and puts his headphones back on.

That's right you lying SOB...I remember exactly the level of personal attacks you spewed on me and other developers behind our backs for using XML as the message format.

Keep your fat ass in your seat and shut the hell up.

Pulled into an 'emergency' meeting with a group of web designers deeply concerned a particular service wasn't going to meet all their requirements.
DevA: "For each page, Its going to be A LOT of work to retrieve all the data and store it's state. Every page load will require a round trip to the service."
DevB: "Yes, we aren't sure how the service should be changed to do what we need."
Mgr: "What is it not doing now? Doesn't the service already returns all the necessary data?"
DevA: "Well...um...its all the boolean fields. Some may be defaulted from the database or false because the user unchecked the box. We have to know which is which"
Me: "Why? Are you doing anything different in the UI? Checkbox will be true or false. What or who set that value is irrelevant"
DevC: "Well, it matters if the user didn't fill out all other other values."
Me: "How so?"
DevA: "Its matters because the values in the other fields. Its going to be A TON of work to figure out."
<mgr goes to the white board>
Mgr: "Lets map this out...what fields are you needing to trigger the state on?"
DevA: "Um...uh...the 'Approved' field...and um...'OK to Contact' field"
Mgr: "Just those two?"
DevA: "Yea..um...there are other fields, but whether or not to show the edit box depends on those two."
Me: "The service already returns data, you only have two fields to check? I don't see a need to change the service at all."
DevA: "Returning all that data, we are going have a serious scaling problem. We'll be hitting the service A LOT. All that javascript could cause performance problems too"
Me: "How much data are we talking about? Name, address, couple of booleans?"
DevA: "I have to serialize the data. All that logic is going to be reeeaaallly complicated. It might be better if the service returned only the data I need."
Me: "$64,000 question, how often is this feature going to be used on the web site? Maybe once? Few hundred a week?"
Mgr: "We have no idea. A lot of the data will be pre-populated and we're only sending out a few thousand invitations. More around the holidays...but honestly, not very many."
Me: "Changing that service only for this particular area of the web site isn't going to happen. Changing the UI is the only course of action."
DevA: "Oh frack I can't wait until this project is over."

DevA...how the funck do still have a job here? You wasted about half-hour of my time with your cry-baby crap. Where is my hammer...no...no..don't go there...ahhh...thanks devrant. Prison sentence diverted.

Some dev makes a claim that a Serialization library won't serialize a field unless it's public

I don't know the library details after but first reaction was "that has to be BS...."

Then I just do a Google search and yes I'm right.

And of course, in my head I go...why the fuck do these ppl not know how to use Google or just RTFM.....

Or use their brains.... If need for serialization required making all fields public that violates the most basic OOP principles...

I upgraded a Linux server one time and data that was serialized in yaml stopped being parsed properly.

It turns out the libyaml people decided to change how hashes were handled, which made any previous hashes come back as blank.

A whole database of valid data in dev was coming back invalid in prod. It was maddening.

It took a day to figure out the problem and how to update the data to the new format in rails.

I now serialize in json.

I'm running into an issue with code coverage... I ran the analysis and it's penalizing unused getter, setters, equals, hashcode.

And the thing is I need those getters so GSON will serialize the fields...

How do you make coverage always > 80%?

Based on current analysis, I only get 60.

The project I have been working on was growing and growing and growing... It reached it a point where the front-end was really hard to maintain. The worst part was the communication protocol, we were using JSON to serialize really complex objects.

I took some initiative and suggested that we use protobuf instead of JSON. Long story short, data usage is 10% of what it used to be, serialization and deserialzation is much faster, and the best of all, everything is strongly typed, with auto generated classes. Fucking awesome!

TLDR: RTFM...

My dad (taught me how to code when I was a kid) was stuck serializing a Java enum/class to XML.... The enum wasn't just a list of string values but more like a Map(String,Object>.

He tried to annotate it with XMLEnum but the moment I saw this enum, I'm thinking that's unlikely to work.... Mapping all that to just a string?

He tried annotating the Fields in it using XMLAttribute but clearly wasnt working...

Also he use XMLEnumValue but from his test run I could clearly see it just replaced whatever the enum value would've been with some fixed String...

Me: Did you read the documentation or when the javadocs?

Dad: no, I don't like reading documentation and the samples didn't work.

I haven't done XML Serialization for years thought did use JSON and my first instinct was... You need a TypeAdapter to convert the enum to a serializable class.

So I do some Googling, read the docs then just played around with the code, figured out how to serialize a class and also how to implement XmlTypeAdapter.... 20 mins ...

Text him back with screenshots and basically:

See it's not that hard if you actually read up on the javadocs and realized ur enum is more like a class so probably the simple way won't work...

Today I discovered that Betheme for Wordpress stores data base64 encoded in the database. Meaning you can't just do a search replace when you migrate a site to a different domain. That combined with Chrome based browsers not loading mixed security assets, but Firefox (the browser I use) does, makes for a confusing trouble ticket.

You have to change the setting to serialize sanely, then go into every post and save to update the stored data. Fortunately, the site is new so I only had one page to update, but I can't imagine the headache an established site would be to migrate.

Question regarding android. I am having a problem with retrofit (I am using moshi converter factory) and hope that you can help.

Basically I have a screen with 3 checkboxes. User is able to select any of these checkboxes, and also user is allowed to select none of them.

When user doesn't select any checkboxes and click complete button, I send a PATCH request to backend with a model which contains 3 null values.

Problem here is that PATCH request which is being sent doesn't include any properties which have been nulled.

I spent some time researching why retrofit/moshi doesn't serialize nulled properties and I found a fix.

So I have this line

.addConverterFactory(MoshiConverterFactory.create(moshi))

Which I replaced with

.addConverterFactory(MoshiConverterFactory.create(moshi).withNullSerialization())

Now nulls are serialized and I am able to send a PATCH request model with nulled values. However now I'm facing another problem. Across my app I'm using only one retrofit client and I don't want to serialize nulls for all requests. Also I don't want to create another retrofit client.

How can I fix this problem? As far as I've researched it seems that I need to add an adapter with toJson() and fromJson() methods and then somehow enable nullSerialization only for that adapter. However I don't completely understand that solution and not even sure how to handle it.

If I kept track of all the hours wasted on issues due to overloads of functions called ToList() it would probably make up a sizable portion of the project budgets.

If I call ToList on a query object, it looks like I'm trying to serialize the query definition into some kind of array. That's what it *should* do with that name. Bonus if the object implements some generic enumerable interface, ToList makes it call your database, you can just toss the query into some json serializer that blocks while calling ToList for you, and people end up doing exactly this because the code turned out so much neater.

Because that's the thing. It's like people implement it because it's "neat" and the user shouldn't care about its internals. How many tears would be shed by just calling it ExecuteAsync?

I guess I'll just die.

Using unity for a commission project:
Have a CCG-like setup, the cards inherit from Scriptable object, need to serialize a card inventory for the sake of persistence.
Attempt 1: XML serialization: get fucked, can't serialize dictionaries (what the hell)
Attempt 2: using data representation of the dictionary contents: get fucked, can't serialize Scriptable objects because they have to be handled by the engine...
Well okay, what if I use a Scriptable object to keep a persistent dictionary?
Attempt 3: Scriptable object with dictionary: get fucked, the dictionary didn't persist
Well now I'm starting to lose it, I've tried so many things, XML, Binary and JSon serialization, Scriptable objects, data representations, I'm really running out of ideas. I can only think of one more option: throw the Card objects into a Resources folder, an build a set of comma delimited strings to serialize. This is stupid.

Fuck Unity. Shit like this is why I'm making my own engine. Every week I find some new peeve, some new way that unity is full of redundancy and poor design, architectural flaws and workflow deficiencies. I don't know how much more of this I can take.

Okay, so I had an object consisting of tables (basically classes) and structs (classes with only scalars as their properties).

I was about to serialize the object with vectors of classes and structs and wrote some nice tests for it wondering why they fail to validate the data after deserialization and why I only got garbage for the vectors of structs whilst the tables worked just fine.

Turns out there is an undocumented function called CreateVectorOfStructs which shall be used for structs instead of the regular CreateVector ...

There go three hours of blaming memory issues and running Valgrind over and over again ...