My React work went well today, I now have my Android app posting data to my server where it's also accessible/modifiable through the web. It looks ugly but it works!

Question: when going to my web page, I'm currently immediately launching a fetch request to grab some data through my REST API. Is this the standard way of doing things, or is there something I should be doing to send the initial data that the user will see along with the initial page load?

The other option would be to render the data with the initial page load so the REST call is not needed?

I think both designs are valid. Would depend on how long this data takes to be generated server-side and how critical it is to the page. You can have better perceived performance if you load the page without the data and then fetch it with a REST call after page load. Also think about how your requirements will change in the future (more data / more server side processing for this data in future)

Ideally all the initial information the app needs (especially if its not deep linked) should be in the response to the initial request. In practice this is like 5-10% of the time. The current crud thing I'm making for my job makes ~5 ajax calls after the app mounts. zz.

The relatively pleasant date handling in Postgres was what pushed me to start using it way back when.

Yeah, I'm curious if this is a common approach and if so, how this would be done in a way that neatly integrates with my frontend code.

Read the slashdot comments in the link I posted - and it was on April 1. Also Mithril is some kind of mythical Dwarf potion or something. It just seemed like they were acting like it was a mutli-year-running April fool's joke. But obviously from the repo it's active. So I was (still am) confused.

There's like 2 people in this comments that think the framework itself is a joke...

The running joke stuff was referring to the ****ty UI slash dot rolls out for April fool's

Sent from my Pixel XL using Tapatalk

Ah. I'm easy to confuse FWIW.

Yes it is common. A good design for it imo is to have the page itself call the API during it's load to get the data it needs (avoids the need to build/maintain 2 ways of getting the data).

Yeah, that could definitely be a factor. I've always worked for companies < 500 people.

I just checked out our job page to make sure we don't have job codes.

Anyone here got Win/IIS experience? This issue is driving me completely nuts:
http://stackoverflow.com/questions/4...47747_43187044

There's probably a problem upstream - you're probably getting a DateTime object with UTC timezone specified in one case and a DateTime object with unknown timezone in the other.

It's hard for me to see where, both servers are running exactly the same compiled application, and retrieving the data from the exactly the sa.....

Ahhhh.....

Just did a test. Values are pulled from Redis. Server setting the value sets it properly, server reading the value doesn't know it's UTC. Looks like it's an issue to do with caching model! Thank you!

This reminds me - there was an earlier discussion about the datetime nonsense in various languages but the main reason why datetime is hard is that it's inherently complex, not merely because programming languages or libraries screwed up. For example:

http://algeri-wong.com/yishan/great-...r-science.html

An example of ****ery I've sort of had to deal with recently for example:

https://www.timeanddate.com/news/tim...-timezone.html

If you want to deal with historical dates correctly, it's not enough to understand the timezone and daylight saving rules today - you have to understand all of the past rules and when they changed.

As an aside, it's interesting that a Facebook guy in 2008 (Yishan Wong, also future ex-CEO of reddit) was calling Microsoft the greatest software company in the world and Google the next greatest software company in the world.

Interesting links, never thought about countries changing timezones! I pitty anyone who has to write these timezone libraries, not something I'd want to wade in to.

My brother always thought one of the reasons MSFT got such good global reach early was because they focused on localisation, eg multi language. I think there's an important lesson there for anyone building software - it's still hard but if you can do it will give you a major competitive edge.

Anybody have any experience with http://www.scaledagileframework.com/?

Thanks for the feedback! The previous course was quite difficult but I enjoyed it and was able to stick it out, so hopefully I'll have a similar experience with this one. Whether I'll be able to reach the level of competence that I need to create the app I have in mind just by taking the course, I don't know, but it should be plenty educational no matter what.

I took one of their train the trainer courses thinking it would be good agile training, one of the founders was an ex-co-worker... Has some interesting ideas on how to move agile from the small company level to the enterprise level. However, highlights how much the rest of the organization needs to be able to do agile instead of just a few dev teams. What are you looking to get out of it?

Was going to mention this, but it is hacky as hell to insert into a database just to select some proper time-zone stuff. I guess you could just write in PL/pgSQL and call those functions, but considering it still looks like a db call...

My company is adopting it full force. I'm pretty skeptical, it smells like water-scrum-fall to me, but maybe its ok, I dunno. Wanted someone to tell me its all going to be ok

Oh yeah - a historical time zone DB becomes gigantic very very quickly. Even a current timezone DB is gigantic if you have to cover the whole world. Moment-timezone gives you a way to create a DB with only the countries/time-zones you're interested in.

Indiana used to go county by county as far as which time zone they were in - and some were offset by 30 minutes. Places in the US used to be off by :15. AZ doesn't do daylight-savings - but the Navajo nation inside it does. Not many sites get that right.

Timezone/daylight savings is the ultimate *never try to roll your own - use a 3rd-party package*.

I haven't programmed Java for 10 years, but as I remember - the whole Calendar implementation was pretty ridiculous. Wait - just to get a standard date format I have to create some instance of a Gregorian Calendar? Wtf.

Sure, I get that it's complex. But most systems have things that are so counter-intuitive that I think the only description you could give would be "they did it wrong"

Take for example, a common problem in python. Say I do this:
This is completely wrong. The reason it's wrong is because python does it in the wrong order. It picks the time zone first and then sets the time. Since there is a history of time zone info for US/Central, it picks the *first* time zone entry in it's list. If instead it instantiated the datetime first, it should have a reasonable crack at picking the "right" version of US/Central for this time.

Instead the way you need to do it is like this

Personally, I think that's broken. And they aren't going to fix it, because it's been there so long that people may be relying on broken behavior. C'est la vie.

I had a one week training course in it from the guy who wrote it who knows his **** forward and backwards so size your grain of salt accordingly. If you can get the planning activity to work, which having seen it have problems in a 100 person company seems like the area with the most problems to avoid I think the rest of it falls into place. Are you using consultants from SAFe for training and lead some of the planning activities?

First day of work and it's new hire orientation all day. Won't be able to meet with my team today.

Are you saying the output python gives you is wrong, or the order is wrong in your opinion?

Python tries to keep things simple (i.e. the user cares about datetime), so there is one interface with an optional argument to change naive to aware.

The popular Django framework seem to agree with your implementation though:

https://docs.djangoproject.com/en/1....one.make_aware