21 Jun, 2011, Runter wrote in the 61st comment:
Votes: 0
Scandum said:
quixadhal said:
Assuming your chosen JSON library ( http://www.json.org/ – take your pick ) doesn't directly support serializing and deserializing arbitrary data structures, it's not that hard to walk your data and either build a simpler structure you can serialize, or emit the appropriate JSON code to store the elements as you go. Reading that back in may not give you a direct load, but it would put all your data in memory where you can then easily move it into the right structures without having to parse it from a clunky file format.

Using that approach something like: { "name" : "A room", "vnum" : 1234 } isn't going to work because in Diku land you can't store the name until you get the vnum.


It boils down to diku highly coupling something that almost certainly shouldn't be.
21 Jun, 2011, quixadhal wrote in the 62nd comment:
Votes: 0
JohnnyStarr said:
Why not just use sqlite?
Your site stores data in the db. The mud accesses that db with the C sqlite library.


The backend isn't the issue, JSON or SQL are equivalent.

Scandum said:
Using that approach something like: { "name" : "A room", "vnum" : 1234 } isn't going to work because in Diku land you can't store the name until you get the vnum. You'd have to store it into a dummy data structure first, and populate the actual data structure when the JSON object is closed. So you're looking at about 10 dummy data structures, each with specific event handling, which means you're basically creating a more complex duplicate of db.c. It'd be doable if you got rid of the old file handling and switched entirely to JSON, though then you also have to add support for area saving.. more work.


But you already have the name and vnum. The whole point is that all the data already exists and is loaded in memory. You don't need 10 dummy structures, you need 1. You can write out the JSON without any dummy structures if you like, and when you read it back in, you load it as a single object and then pluck the data out, pushing it into your game's data structures as needed. The only difference between this and the normal way of doing it, is you don't need to sit and parse the file format.

Like XML libraries, I'd expect most of the JSON libraries to support searching and counting nodes, so converting from the reloaded JSON data back to native should be pretty easy.
22 Jun, 2011, Rarva.Riendf wrote in the 63rd comment:
Votes: 0
JohnnyStarr said:
Also, the main advantage of a web front-end is sharing information with others. I'm sure it would be
easier to develop a desktop application to do this (there are quite a few out there).

I am sure it is as well, and an applet could do both easily, ha well…
22 Jun, 2011, plamzi wrote in the 64th comment:
Votes: 0
Rarva.Riendf said:
JohnnyStarr said:
Also, the main advantage of a web front-end is sharing information with others. I'm sure it would be
easier to develop a desktop application to do this (there are quite a few out there).

I am sure it is as well, and an applet could do both easily, ha well…


I think it bears reminding that web browser apps are instantly ubiquitous in a way that no other applications are. Yes, everything is a lot harder to do in a web app. Is it worth the trouble? Absolutely.
22 Jun, 2011, Runter wrote in the 65th comment:
Votes: 0
Rarva.Riendf said:
JohnnyStarr said:
Also, the main advantage of a web front-end is sharing information with others. I'm sure it would be
easier to develop a desktop application to do this (there are quite a few out there).

I am sure it is as well, and an applet could do both easily, ha well…


Are you talking about java/flash embedded, or something else?
22 Jun, 2011, Rarva.Riendf wrote in the 66th comment:
Votes: 0
Runter said:
Are you talking about java/flash embedded, or something else?

Yes java embedded, it is quite easy to code so both the java applet and a stand alone jar works the same graphically. both can write files on the desktop and quite easily communicate to a distant server as well. And then you haveal the advantages. Off course it requires java, but it is no more different than using the flash player.
Imho, it is the best of both world. Java has been overlooked in applet at the beginning cause awt basically sucked, and its reputation really suffered from that, but you can prettry much embed eclispe in an applet if you wanted it. All those 'cloud application' using this abomination that is javascript to replicate what a proper java code could do kinda makes me sad.
22 Jun, 2011, oenone wrote in the 67th comment:
Votes: 0
HTML5 can do a lot, can write files to the desktop, and communicate to distant servers, too.

You can even use it for native applications (Windows 8 is said to use HTML5 for GUI stuff).
22 Jun, 2011, plamzi wrote in the 68th comment:
Votes: 0
Rarva.Riendf said:
Runter said:
Are you talking about java/flash embedded, or something else?

Yes java embedded, it is quite easy to code so both the java applet and a stand alone jar works the same graphically. both can write files on the desktop and quite easily communicate to a distant server as well. And then you haveal the advantages. Off course it requires java, but it is no more different than using the flash player.
Imho, it is the best of both world. Java has been overlooked in applet at the beginning cause awt basically sucked, and its reputation really suffered from that, but you can prettry much embed eclispe in an applet if you wanted it. All those 'cloud application' using this abomination that is javascript to replicate what a proper java code could do kinda makes me sad.


Clearly, you're a big fan of Java and it may be difficult to admit that it's been going the way of the dinosaur for a long time now. And so is Flash. The final blow to both will probably be dealt by HTML5, as soon as browsers start to natively support/enable all its functionality.

The cloud of the future has to support all mobile clients, and the "abomination" that is JS is already safely in that haven. For many complicated reasons, it doesn't look like Java will be able to cross over. If you make a Java applet, it will not be ubiquitous, no matter how much you wish it to be.

Java has a safe future on the server side, but as a client-side option, it no longer seems viable.
22 Jun, 2011, Runter wrote in the 69th comment:
Votes: 0
I don't like using flash or java here. Honestly, those options seem like the "abomination" to me. Fwiw, I use java, but not to replace web architecture. For a while now a lot of people who feel the same way has been using flash and java as a rope bridge to the future, but I know a lot of developers who will forsake it the moment there's good support across clients for html5, and we're rapidly approaching that point.
22 Jun, 2011, kiasyn wrote in the 70th comment:
Votes: 0
plamzi said:
The cloud of the future has to support all mobile clients, and the "abomination" that is JS is already safely in that haven. For many complicated reasons, it doesn't look like Java will be able to cross over. If you make a Java applet, it will not be ubiquitous, no matter how much you wish it to be.
Java has a safe future on the server side, but as a client-side option, it no longer seems viable.


Android apps are primarily java based, but I don't think applets are. There still is room for Java in some parts of the future, but embedded Java webapps has always been an issue.
22 Jun, 2011, JohnnyStarr wrote in the 71st comment:
Votes: 0
I'm curious where things are going to go web-wise myself.
I have to admit I haven't really researched it much, but it seems that CMS sites are replacing a lot of
hand written sites. At least in the blog / social network world.

I have been wanting to get into web design professionally. Any suggestions? I have been learning Ruby on Rails
and PHP along with mySQL, CSS, AJAX.

I hate to spend a lot of time learning something that is going to go soon though.
22 Jun, 2011, Runter wrote in the 72nd comment:
Votes: 0
html/css/javascript aren't going anywhere any time soon. On the backend you should learn what you're comfortable with. And there's a plethora of languages that are acceptable there. PHP, frankly, is one of my least favorite. Ruby and Python are both popular choices as well.

The database language isn't a big deal. AJAX is just a design pattern.
23 Jun, 2011, plamzi wrote in the 73rd comment:
Votes: 0
PHP has fallen out of the limelight these days, but it seems to me it's usually for reasons like "Python is always faster" or "Ruby is sooo much easier," which are all true… half the time. There are tons of open-source projects, including CMS like Joomla and Drupal, that use PHP and it's still very much worth knowing, in my book. I dabbled in Joomla CMS as a hobby for several years and it's now part of my resume–if you're looking to learn some MVC concepts through tinkering, I highly recommend it as a playground.

As long as you steer clear of ASP, there really is no server-side script that would waste your time. Ruby is most likely to land you a job nowadays… And hey, what do you know, C is coming back in the web world, with sites like Facebook building PHP wrappers around a speedy "engine" core in C. Or so I hear.
23 Jun, 2011, Runter wrote in the 74th comment:
Votes: 0
plamzi said:
PHP has fallen out of the limelight these days, but it seems to me it's usually for reasons like "Python is always faster" or "Ruby is sooo much easier," which are all true… half the time.


I boils down to PHP is gross. The language grew out of a template system with hodgepodge constructs for which orthogonality was only an afterthought. The whole thing is haphazard and awkward. I'd use just about anything else before using PHP. The PHP community itself has issues with using proper frameworks and patterns like MVC. Only in recent years has stuff like CakePHP made it to the scene, and they're nasty compared to Rails or Django, or any other sensible framework+language combo. If you want the inconvenience of C and the inefficiency of a high level language then PHP is great stuff. To be fair to C, at least it's somewhat consist. The trashy global namespace of PHP and the inconsistency of the function naming is ridiculous.
23 Jun, 2011, kiasyn wrote in the 75th comment:
Votes: 0
plamzi said:
As long as you steer clear of ASP, there really is no server-side script that would waste your time. Ruby is most likely to land you a job nowadays… And hey, what do you know, C is coming back in the web world, with sites like Facebook building PHP wrappers around a speedy "engine" core in C. Or so I hear.


Classic ASP I assume, not ASP.NET?
23 Jun, 2011, David Haley wrote in the 76th comment:
Votes: 0
Plamzi said:
with sites like Facebook building PHP wrappers around a speedy "engine" core in C

Nearly very serious data processing will be written in a language like C/C++. This is most typically true in applications that need to crunch very large amounts of data, like search engines, financial applications, massively data-intensive sites like Facebook, Amazon, etc.


IMHO, getting on a soapbox a bit, it gets a little old to hear about this or that language being more "in fashion". If you're a good developer with a solid understanding of the concepts, then the language can be picked up fairly quickly – and a good employer will understand that as well. For example, somebody who knows Python, PHP, Java, C++ and Lua will be able to pick up Ruby quite quickly. (The statement holds true for other combinations, I just picked those off the top of my head.)
So hearing that this or that language will waste your time kind of rubs me the wrong way. It's never a waste of time to learn programming concepts, as long as you're realizing that the concepts are separate from whatever particular syntax you're using. If you're understanding what it means to loop over lists, then doing it with a for loop in C or in PHP isn't hugely different.
OK, ok, enough with the soapbox…
24 Jun, 2011, plamzi wrote in the 77th comment:
Votes: 0
David Haley said:
IMHO, getting on a soapbox a bit, it gets a little old to hear about this or that language being more "in fashion". If you're a good developer with a solid understanding of the concepts, then the language can be picked up fairly quickly – and a good employer will understand that as well. For example, somebody who knows Python, PHP, Java, C++ and Lua will be able to pick up Ruby quite quickly. (The statement holds true for other combinations, I just picked those off the top of my head.)
So hearing that this or that language will waste your time kind of rubs me the wrong way. It's never a waste of time to learn programming concepts, as long as you're realizing that the concepts are separate from whatever particular syntax you're using. If you're understanding what it means to loop over lists, then doing it with a for loop in C or in PHP isn't hugely different.
OK, ok, enough with the soapbox…


I agree that fashions in languages (like fashions in anything) are superficial and that the fundamentals making people good at coding are totally agnostic. That said, if you're looking to hone your skills for the job market, it would be foolish to ignore trends just because you don't believe in them.

I've heard say that Ruby is hot in California, with lots of demand for people who can write it fast and well. Now, you can list all those other languages on your resume and hope that someone else who doesn't believe in fashions picks you out from the crowd as someone who can learn Ruby fast. Or, you can get some hobbyist experience with Ruby and add it to the list. If I were on the web developer job market, applying for positions like "Ruby Developer," I would do the latter.
24 Jun, 2011, Runter wrote in the 78th comment:
Votes: 0
It's no different from any other tool an employer might expect you to be proficient in. If you're applying at a shop where they use Ruby it's reasonable for them to primarily look for someone that knows the tool. Same thing goes for Python, or any other language. That being said, It's extremely common for employers to give experienced employees a grace period to learn these tools. What's not common is coming straight out of school with no experience or portfolio to show and expecting on the job training necessarily. That's usually what internships are for. (And some of us did them unpaid.)

And I don't really understand why you're calling this a fad. These employers aren't asking for ruby developers because they read on a blog that ruby is cool. They're asking for them because they usually have a team and/or projects dealing in Ruby prior to your theoretical employment. It's usually more rare to see mixed development with different languages that achieve the same thing. That's extremely onerous for small and medium sized companies.
24 Jun, 2011, plamzi wrote in the 79th comment:
Votes: 0
Runter said:
And I don't really understand why you're calling this a fad. These employers aren't asking for ruby developers because they read on a blog that ruby is cool. They're asking for them because they usually have a team and/or projects dealing in Ruby prior to your theoretical employment. It's usually more rare to see mixed development with different languages that achieve the same thing. That's extremely onerous for small and medium sized companies.


Well yes, but how did it happen that almost overnight 9 of 10 projects began to demand Ruby? The fad is among the customers, not among developer firms. It's got to be a fad because you know there are half a dozen capable languages that can do what Ruby does, and hordes of developers experienced in those, yet it looks like 90% of the market demands Ruby and there's a glut. If it were up to developer firms, they would rather not have to compete for the next able-bodied Ruby developer and leverage the experience of their existing staff to get the job done, gradually easing their employees into newer tools. But, I imagine, the customers feel differently–and they're always right.

It's a good thing for any industry when a new fashion comes into town, because you get to sell your customers the same dress you sold them last year, but with the sleeves cut off.
24 Jun, 2011, Runter wrote in the 80th comment:
Votes: 0
Those statistics aren't even close to correct. It may seem like there's more Ruby demand because there aren't as many Ruby developers.
60.0/85