switch to room list switch to menu My folders
Go to page: First ... 19 20 21 22 [23] 24 25 26 27 ... Last
[#] Fri Jul 22 2016 11:21:41 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

Render a skeleton of the page the main page load, and populate the full contents asynchronously. Surely that's the whole reason you wanted to use AJAX in the first place, so it is the best practice.

[#] Sun Jul 24 2016 21:02:49 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

For the most part, yes. Initially however I'm making a call that loads a bunch of system configuration (in JSON format) and populates a bunch of data structures. This determines how the remainder of the page gets rendered.
Once that's done, nearly everything else can happen asynchronously.

Admittedly, however, I am a n00b to writing web applications this way, and as soon as it's implemented past the point of no return I'll figure out a better way to do it.

[#] Mon Jul 25 2016 11:44:52 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

of data structures. This determines how the remainder of the page gets


Then it sounds like you need to render *almost nothing* on the main page load. Render everything from Javascript.

It's either that, or do more of that first, skeletal rendering server side, the old-fashioned way.

[#] Tue Jul 26 2016 21:02:02 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Isn't that how you're supposed to do client-side web apps anyway? Just a couple of div's for the basic layout and then everything else in javascript?

What I ended up doing is running the initial JS piece on page load and then having that function's OnComplete (or whatever it's called) call a function that loads all the other pieces that depend on it. I suppose that's "how it's supposed to be done" but it still seems a bit obtuse to me.

[#] Fri Jul 29 2016 09:19:12 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

Yeah, that's how the cool kids do web development these days, daddy-o.

*snap* *snap* Fresh.

[#] Mon Oct 03 2016 11:47:22 EDT from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

I have written a fairly significant amount of Rails code lately.

I thought we should embrace it, as the rest of the company uses it for their efforts, so we could potentially pull from a larger pool of people in the future if we ever needed to do so.

Although I'd never used this before, I find this environment impressive.
Although, getting something up in production seemed to involve installing the world.

[#] Sat Nov 19 2016 07:11:37 EST from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

I might have an illness.

I've been spending my free time writing a C++ header library to act as an HTTP 1.1 client.

Handling chunked transfer encoding or regular 'identity' transfer encoding, getting headers, able to write the body either to memory or file, etc.

I never found a truly C++ library that quite did all of this the way I want, so I figured I should write my own. There's this one guy, named Falco, working on something that looks nice, but it requires C++11 or better, and I don't want to be limited to newer compilers for this.

I think after I get the client side working, I want to see how much of this I can reuse/rework for server side. I'll never replace apache, but if someone needed an embedded http 1.1 server, maybe I can make this interesting.

[#] Sat Nov 19 2016 07:12:37 EST from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

(And, yeah, it can handle http or https... technically, I think it could transfer across serial ports or any other transport if you built the low end for it).

[#] Mon Nov 21 2016 14:00:18 EST from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

Apparently Java can't get this right, either. Apache httpcore is a mind-bogglingly large API.

[#] Mon Nov 21 2016 18:11:27 EST from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

waitwaitwhat? All this getting done in headers? Is C++ truly this brain damaged or am I missing something?

[#] Tue Nov 22 2016 13:24:56 EST from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

Pretty much, yeah. Doing everything with templates and type-safety means doing it in headers. It's a suboptimal state of affairs.

[#] Tue Nov 29 2016 12:33:36 EST from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

Well, one could turn it into a proper .lib or .so library if desired, but why bother when you can distribute a bunch of headers and not have to worry about how the shared object was compiled, or with what will it link?

[#] Tue Nov 29 2016 17:27:32 EST from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

compile time. an object-oriented http library, which is reasonably full-featured and modular, is going to be highly layered and rather large.

you may be building something lean and mean that's just good enough for your needs, but not really general-purpose.

[#] Thu Dec 01 2016 08:57:50 EST from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

Yeah, header libraries can increase compile time when you do things like include base headers that include tons of other header files, instead of just pulling the header files you need in the library.

If you build the header library carefully, you can reduce the compile to just what is needed, which often doesn't require that much time to compile.

And if your compile times *still* grow to something kind of nuts, you can probably do something clever with your own implementation files to reduce compile times, by moving the often-changing stuff to places that don't pull in header libraries.

Eh, I probably just haven't had a big issue with compile times. My current project requires about 7 minutes to fully compile everything (both 32 and 64 bits, so I have to compile everything twice).

[#] Thu Dec 01 2016 09:36:19 EST from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

On an unrelated note, I saw something today that does a great job of explaining why 'const' is a good thing, and not to be trifled with.

void a(std::string var) {
char* tok = strtok(const_cast<char*>(var.c_str(), " ");
while (tok) {
tok = strtok(0, " ");

int main() {
std::string var = "moo bark quack";
return 0;

(aside from not having created 'fn()'), this code is evil.

You figure, "Oh, no big deal... a() uses a copy of the std::string, since this isn't passed by reference, so the const_cast won't lead to any problems."

Except you didn't know that some vendors won't actually copy the string used by the std::string class until some operation takes place that requires it... and .c_str() isn't that operator, since it's protected by const.

So, your function now leads to side effects that burns your coworkers.

[#] Thu Dec 01 2016 09:37:16 EST from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

Ugh... forgot a paren in that code... trying to write it on-the-fly.

[#] Thu Dec 01 2016 09:45:23 EST from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

const's virus-like behavior is quite challenging in C++. Java probably strikes a better balance by simply accepting that some things are out of our control at compile time.

[#] Thu Dec 01 2016 11:39:46 EST from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

Maybe, although in this case, it did its job.

My eye zeroed in on the const_cast immediately, and it highlighted the problem.
I was able to deduce the issue and solve the problem in very short time because I could see something odd was going on (one almost never needs to const_cast... it's just one of those things that screams at you when you see it).

It's like type safety... I know tons of people hate it, because it seems to prevent people from getting code written, but that early detection helps avoid many terrible issues that come up when you accidentally mix types. Seeing things like reinterpret_cast or static_cast helps draw your eye on possible problems when you're trying to figure out why something went off.

[#] Thu Dec 01 2016 14:24:01 EST from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

In Java, the type system is just less expressive. Primitive types can be "const"; actually the word for this is "final" in Java. A reference to an object is a primitive type. If the reference is "final", the reference can't be modified but the object it refers to *can*, so long as there is at least one non-final field in that object. Unlike C++ there's no notion of a struct or class that contains non-const fields but a particular instance of or reference to the struct could be declared const. So you can't express quite such binding constraints in the type system.... but you spend less time fighting with the compiler because of somebody else's lack of foresight.

[#] Thu Dec 01 2016 14:39:42 EST from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]

Java wasn't an option for our needs, though.

I use it when dealing with ESXi and certain other situations, but not for some of this work we're doing.

Go to page: First ... 19 20 21 22 [23] 24 25 26 27 ... Last