| Time |
S |
Nick |
Message |
| 01:52 |
|
|
Guest53835 joined ##javaee |
| 02:10 |
|
|
sfisque joined ##javaee |
| 03:16 |
|
|
sfisque1 joined ##javaee |
| 03:53 |
|
|
jenue joined ##javaee |
| 05:06 |
|
|
cem__ joined ##javaee |
| 05:07 |
|
cem__ |
ohayo |
| 05:08 |
|
* cem__ |
time to wake sfisque |
| 05:08 |
|
cem__ |
:D D |
| 05:18 |
|
|
sross_work|2 joined ##javaee |
| 05:40 |
|
|
dangertools joined ##javaee |
| 05:40 |
|
|
dangertools joined ##javaee |
| 06:54 |
|
|
Quest joined ##javaee |
| 06:54 |
|
Quest |
it is prerequisit to pass oracle certified associate if one wants to attempt oracle certified programmer exams? |
| 06:54 |
|
Quest |
any one certified and can coment on the exams? |
| 06:58 |
|
|
Centauri joined ##javaee |
| 07:36 |
|
|
pleroma joined ##javaee |
| 08:23 |
|
|
NerdKelly joined ##javaee |
| 08:39 |
|
|
sfisque joined ##javaee |
| 09:06 |
|
|
AlexCzar joined ##javaee |
| 09:09 |
|
|
Lappro joined ##javaee |
| 09:10 |
|
|
kinabalu_ joined ##javaee |
| 10:15 |
|
|
NerdKelly joined ##javaee |
| 10:26 |
|
|
jason_ joined ##javaee |
| 10:52 |
|
acuzio |
Quest: The exams are wonderful - you should take them |
| 10:54 |
|
Quest |
did you took any? |
| 10:55 |
|
acuzio |
No |
| 10:55 |
|
acuzio |
But i know people who did |
| 10:56 |
|
|
jason_ joined ##javaee |
| 11:24 |
|
|
knoppix joined ##javaee |
| 12:32 |
|
Quest |
k |
| 12:52 |
|
acuzio |
Quest: you should take it up , it will help others |
| 12:54 |
|
Quest |
k |
| 13:09 |
|
neuro|sys |
folk, I'm really only recently getting into frontend development |
| 13:10 |
|
neuro|sys |
I'd like some opinions about the technologies to be used |
| 13:17 |
|
neuro|sys |
discovered and tried several stuff like angularjs, emberjs, meteor.js, and handlebars, or YUI, dojo, pure jquery. there's just too many stuff out there with fundamental differences. |
| 13:17 |
|
neuro|sys |
should stick to one and go with it |
| 13:29 |
|
pdurbin |
neuro|sys: what are you using now? |
| 13:32 |
|
neuro|sys |
there's nothing much yet really except a table |
| 13:32 |
|
neuro|sys |
there's one widget I needed to make was basically a table with data updated through websocket calls. I simply send the json, and build the table from scratch with jquery, and update/animate. |
| 13:33 |
|
neuro|sys |
pdurbin: have a look at this: http://96.126.113.153/ |
| 13:34 |
|
neuro|sys |
note that I'm really noob at JS and pretty much anything regarding frontend |
| 13:35 |
|
pdurbin |
neuro|sys: looks fine |
| 13:46 |
|
pdurbin |
neuro|sys: I guess ask yourself if you want to do MVC in the client (i.e. angular) or the server (i.e. JSF) |
| 13:47 |
|
neuro|sys |
pdurbin: I've already answered that, and want MVC on the client |
| 13:47 |
|
neuro|sys |
I'd like to send only data/json over the wire |
| 13:48 |
|
neuro|sys |
I've been using JSF at work for browser based apps. I'd like to explore the otherway around, which I think is neater, as acuzio convinced me recently |
| 13:48 |
|
pdurbin |
in that case, angular seems popular. I'd try that first |
| 13:50 |
|
neuro|sys |
yes will do that |
| 13:50 |
|
neuro|sys |
meteor.js is very interesting though |
| 13:50 |
|
pdurbin |
semiosis: you have opinions on this stuff |
| 14:01 |
|
pdurbin |
neuro|sys: what do you like about meteor vs. angular? |
| 14:03 |
|
acuzio |
neuro|sys: meteor is not mature enough |
| 14:25 |
|
neuro|sys |
pdurbin: here's a short screencast |
| 14:25 |
|
neuro|sys |
http://www.meteor.com/screencast |
| 14:26 |
|
neuro|sys |
basically it automatically and fully synchronizes client state with the backend |
| 14:26 |
|
neuro|sys |
here's a website completely built with it |
| 14:26 |
|
neuro|sys |
https://coinex.pw/ |
| 14:30 |
|
|
jieryn joined ##javaee |
| 14:30 |
|
|
jieryn joined ##javaee |
| 14:31 |
|
neuro|sys |
haha, a jenkins dev |
| 14:31 |
|
pdurbin |
neuro|sys: any backend? |
| 14:32 |
|
neuro|sys |
pdurbin: I guess backend has to be JS/Node.js, but I'm not sure. |
| 14:32 |
|
neuro|sys |
if the backend is only JS, I'd rather not use it |
| 14:33 |
|
pdurbin |
yeah, probably node |
| 14:33 |
|
neuro|sys |
although should be possible to bind calls to elsewhere |
| 14:37 |
|
|
Vivekananda joined ##javaee |
| 14:38 |
|
|
sheenobu joined ##javaee |
| 14:39 |
|
Vivekananda |
hi |
| 14:41 |
|
pdurbin |
Vivekananda: hi |
| 14:43 |
|
|
sheenobu joined ##javaee |
| 14:44 |
|
Vivekananda |
i work on python and spring , this place right to ask question on that |
| 14:50 |
|
|
Vivekananda left ##javaee |
| 14:57 |
|
|
cem__ joined ##javaee |
| 15:01 |
|
|
cem__ left ##javaee |
| 15:02 |
|
|
Naros joined ##javaee |
| 15:03 |
|
neuro|sys |
this firebase thingie also looks interesting. :) |
| 15:04 |
|
pdurbin |
I'm using java.util.logging and typing `logger.info("indexing...");` but from looking at glassfish's server.log you'd think I'm prepending a newline like this: `logger.info("\nindexing...");`. Anyone know how to fix this? |
| 15:04 |
|
neuro|sys |
do you have an appender/encoder configuration? |
| 15:05 |
|
neuro|sys |
it probably goes through a handler or something |
| 15:06 |
|
pdurbin |
hmm. dunno. it's a fresh glassfish 4 install |
| 15:17 |
|
|
cem__ joined ##javaee |
| 15:17 |
|
cem__ |
hi |
| 15:17 |
|
cem__ |
somehow i was banned by freenode |
| 15:18 |
|
neuro|sys |
all the webchat clients were, I guess |
| 15:18 |
|
pdurbin |
javaeebot: lucky firebase |
| 15:18 |
|
javaeebot |
pdurbin: https://www.firebase.com/ |
| 15:20 |
|
cem__ |
wht is tht pdurbin ? |
| 15:21 |
|
pdurbin |
"Firebase lets you create fully interactive apps with just frontend code. Stop thinking about servers and databases and focus on your application logic and your customers." |
| 15:21 |
|
pdurbin |
cem__: neuro|sys found it |
| 15:26 |
|
semiosis |
pdurbin: my opinion is use the right tool for the job. |
| 15:26 |
|
semiosis |
neuro|sys: what is the job you're trying to do? |
| 15:29 |
|
neuro|sys |
semiosis: I'm simply learning frontend web dev :P |
| 15:29 |
|
neuro|sys |
Actually do all UI on the client |
| 15:30 |
|
neuro|sys |
send/receive only json between the client and the server |
| 15:31 |
|
semiosis |
what do you want to build? what is this a front end for? |
| 15:32 |
|
semiosis |
maybe this will help... http://todomvc.com/ |
| 15:32 |
|
cem__ |
what are you trying to learn |
| 15:32 |
|
semiosis |
a todo list app built in lots (& lots) of different frontend frameworks |
| 15:32 |
|
neuro|sys |
semiosis: great, I'll check |
| 15:32 |
|
cem__ |
great share |
| 15:33 |
|
neuro|sys |
I'm planning to build a website with real-time updated data |
| 15:33 |
|
neuro|sys |
with graphical charts and tables |
| 15:37 |
|
cem__ |
#xml |
| 15:39 |
|
pdurbin |
that's why we keep semiosis around |
| 15:39 |
|
cem__ |
k my doubt is this often the sensex are built on some web application and how reliable are they ? |
| 15:42 |
|
cem__ |
that's why we keep semiosis around ? |
| 15:43 |
|
pdurbin |
for the great shares |
| 16:14 |
|
cem__ |
http://www.ibtimes.com/google-pays-17-million-over-privacy-breach-how-why-google-exploited-safari-1476838 |
| 16:14 |
|
cem__ |
google is ur friend ? |
| 16:19 |
|
|
drspockbr joined ##javaee |
| 16:21 |
|
|
Guest53835 joined ##javaee |
| 16:40 |
|
|
jieryn joined ##javaee |
| 16:45 |
|
|
kobain joined ##javaee |
| 17:28 |
|
acuzio |
no google is not your friend - |
| 17:37 |
|
whartung |
Google is a tick, buried in your armpit |
| 17:46 |
|
pdurbin |
:) |
| 18:04 |
|
sfisque |
google armpit(™)…. because glasses are for nerds…. |
| 18:04 |
|
sfisque |
:P |
| 18:20 |
|
whartung |
:D |
| 18:21 |
|
whartung |
configuring openmq cluster this morning... |
| 18:21 |
|
whartung |
see if I can get it working with GF |
| 18:48 |
|
|
liecno joined ##javaee |
| 19:07 |
|
semiosis |
how many LOC is too many for a method? a class? |
| 19:24 |
|
whartung |
dunno, kind of depends |
| 19:52 |
|
semiosis |
whartung: on what? and what's the range anyway? |
| 19:58 |
|
Naros |
there is no hard rule on LOC limits and really can vary depending on the context. |
| 19:59 |
|
Naros |
Whats the purpose of the class and/or method? Is it more of a top level method or a lower level method invocation for example. |
| 20:06 |
|
semiosis |
how about a soft rule/guideline then? thinking about normal business logic you'd find in just about any javaee app |
| 20:06 |
|
semiosis |
not weird stuff like network protocol stacks or binary file parsers |
| 20:08 |
|
Naros |
CheckStyle defaults to 50 lines / method |
| 20:09 |
|
Naros |
Class lines of code defaults to 1500 lines |
| 20:09 |
|
semiosis |
interesting |
| 20:09 |
|
Naros |
Keep in mind those are just probably some random numbers that are meant as a guide but would vary depending on projects. |
| 20:10 |
|
semiosis |
i try to keep things near about 5 lines, much more than that and the tests get unwieldy |
| 20:10 |
|
Naros |
One of our projects, we modified check style to allow I believe no more than 20 lines / method |
| 20:10 |
|
Naros |
aye, but keep in mind methods often need sanity checks & catches that consume those # of lines |
| 20:10 |
|
semiosis |
i also like that with methods around 5 lines the code becomes "self documenting" |
| 20:11 |
|
Naros |
Aye, as long as the method does what you call it and nothing more, that's pretty much a given regardless of the LOC |
| 20:12 |
|
Naros |
my #1 rule is if I have to write similar code more than once, its grounds for a refactor |
| 20:13 |
|
semiosis |
i used to only make a method when the code would be reused, but since i've been doing TDD i've started making methods for just about everything |
| 20:13 |
|
Naros |
that will generally lead you into breaking down monolithic methods into small chunks and falling in line with decent LOC limits. |
| 20:15 |
|
Naros |
Aye, decomposing methods into smaller ones isn't bad at all |
| 20:15 |
|
Naros |
But you asked about class LOC. I think I have several classes that probably push somewhere around 25,000 LOC easily |
| 20:16 |
|
semiosis |
i have an opinion about method LOC, but not about class LOC so I was more interested to hear if anyone else had one |
| 20:16 |
|
semiosis |
25kLOC in a class does sound pretty extreme |
| 20:16 |
|
Naros |
hehe, yah I have a few monolithic service classes :P |
| 20:17 |
|
Naros |
Rather than having Spring create multiple singletons, I simply use a single one. |
| 20:18 |
|
Naros |
But I am dealing with those classes now, probably wont exceed around 3k each |
| 20:18 |
|
Naros |
hopefully much less |
| 20:19 |
|
Naros |
They suffered from code bloat and the cut-n-paste code syndrome without any concerns about refactoring :P |
| 20:24 |
|
|
sheenobu joined ##javaee |
| 20:24 |
|
|
sheenobu joined ##javaee |
| 20:36 |
|
sfisque |
depends semiosis. like naros was saying, there are constructs that will eat up LOC quickly. basically a method should answer these sanity checks… 1) does it perform (and only perform) the action that matches the method name…. 2) are there side effects that are not obvious or trivial from an outside caller perspective? |
| 20:37 |
|
sfisque |
if it answers those questions in a sane manner, it really doesnt matter if its 1 line or 1k lines |
| 20:41 |
|
semiosis |
seems to me if it's 1k lines and answers all those questions sanely, then it could just as easily be a few lines calling helper methods (which call other helpers) to do the job |
| 20:41 |
|
semiosis |
levels of abstraction |
| 20:42 |
|
sfisque |
depends. there's no reason to externalize code if its getting performed once and only once in the workflow |
| 20:42 |
|
semiosis |
i guess thats a matter of taste |
| 20:42 |
|
sfisque |
fragmenting only offers advantage if you're navigating that path multiple times from different avenues |
| 20:42 |
|
semiosis |
i'd say there's no reason to combine discrete functions into larger methods |
| 20:43 |
|
semiosis |
interesting to see how people differ on this |
| 20:43 |
|
sfisque |
discrete is a matter of scope. if i need to perform lots of preflight to make a call to a webservice and i'm only doing that in one place, what is the advantage of fragmenting the method? |
| 20:43 |
|
sheenobu |
anyone have any non-trivial examples of this. |
| 20:43 |
|
sfisque |
you can look at the entire TX with the ws as discrete |
| 20:44 |
|
semiosis |
sfisque: testability/readability mainly |
| 20:44 |
|
sfisque |
aye, but what's the point of testing fragments if you need it to run properly as a whole discrete unit in one location of the product? |
| 20:45 |
|
semiosis |
if it's critical code, i do both |
| 20:45 |
|
sfisque |
now if i had preflight steps that were useful to other mechs, then yes, i would abstract them out |
| 20:45 |
|
sfisque |
otherwise, it's unnecessary code motion |
| 20:45 |
|
sheenobu |
what would a 'preflight' step be? |
| 20:45 |
|
sheenobu |
prepping the request? validating the input? building the request? |
| 20:45 |
|
sfisque |
building the headers for the call. populating the send record from the passed in var(s) |
| 20:46 |
|
sfisque |
validation should happen before we start to commit to the remote end |
| 20:46 |
|
sfisque |
by the time you enter a call to a remote service that data passed in on the stack better be fullly vetted |
| 20:46 |
|
sheenobu |
sfisque: of course |
| 20:50 |
|
sheenobu |
despite their single use case, all of those seem to be composable (sp?) blocks |
| 20:52 |
|
sheenobu |
i'm partial to camel for stuff like that. input -> validateParams -> setHeader(s) -> markdown:filename.md -> validate XML -> soap client -> validate response -> parse response |
| 20:55 |
|
|
Guest53835 joined ##javaee |
| 20:55 |
|
semiosis |
camel is pretty neat |
| 21:08 |
|
sheenobu |
i like it |
| 21:16 |
|
sfisque |
it definitely has some nice features, though they need to better document how to talk to it from an agnostic standpoint. i had to cruise through the codebase to figure out how to send JMS to it without bundling camel and all it's spring kruft on the client side |
| 21:27 |
|
|
NerdKelly joined ##javaee |
| 21:40 |
|
sheenobu |
sfisque: yeah the default jms camel provider is spring-jms |
| 21:40 |
|
sheenobu |
but if you are sending it JMS you can just create a JMS client and call it (I'm thinking) |
| 21:40 |
|
whartung |
well a simple example is say you have a table with a bunch of columns. It's ugly, but not unheard of, even for "good schemas", to have a table with 100-200 columns. |
| 21:40 |
|
sfisque |
you can. i did a write up on how to do it…. link coming in a second |
| 21:40 |
|
sheenobu |
oh nice |
| 21:41 |
|
whartung |
inserting a row in to that table is flat out going to take a lot of code. |
| 21:41 |
|
whartung |
and it's rote, boilerplate, but that's what it is. |
| 21:42 |
|
sfisque |
https://www.latticeware.com/wiki/Wiki.jsp?page=GlassfishAMQConfigCommunicate |
| 21:42 |
|
sheenobu |
If you map that to a pojo, ala JPA, you can have some of those columns within embedded entities. |
| 21:43 |
|
sheenobu |
sfisque: Id |
| 21:44 |
|
sheenobu |
I'd ask why you didn't just use AMQP directly, but there are a few reasons for that I'd guess, biggest being how terrible amqp support in camel is sometimes |
| 21:44 |
|
* semiosis |
using camel with aws sqs & json messages |
| 21:44 |
|
semiosis |
camel on the consumer, just jackson & aws sdk on the producer |
| 21:44 |
|
sfisque |
why would you write to a proprietary protocol when you can talk vanilla jms via a connection factory provided by the container (rar) |
| 21:45 |
|
sfisque |
the whole point was generic decoupling |
| 21:45 |
|
sfisque |
the code doesnt care whats on the other side. the whole point of jms |
| 21:45 |
|
semiosis |
sfisque: was that to me or sheenobu? |
| 21:45 |
|
sfisque |
proper loose coupling |
| 21:45 |
|
sfisque |
sheenobu |
| 21:46 |
|
sheenobu |
wait wait? amqp is a proprietary protocol and JMS is not? not saying JMS isn't a standard but AMQP is as well. a bad one but a standard non-the-less |
| 21:46 |
|
sfisque |
i'm assuming you mean active mq protocol, no? |
| 21:46 |
|
sfisque |
which is a specific product that uses jms |
| 21:46 |
|
sheenobu |
AMQP is an OASIS stsandard |
| 21:47 |
|
sheenobu |
http://www.amqp.org |
| 21:47 |
|
sfisque |
ah. still, why wouldnt u just register an amqp driver (rar/sar) to the container and have your code just talk vanilla jms? |
| 21:47 |
|
sfisque |
that way you can swap in./out impls and not care |
| 21:47 |
|
sfisque |
deployment issue rather than code issue then |
| 21:48 |
|
sheenobu |
yeah I agree with that |
| 21:48 |
|
sfisque |
i'm a big fan of "make it a deployment issue so i can get on to bigger issues :-)" |
| 21:48 |
|
sheenobu |
this is my AMQP right now: "Work Scheduler Queue Size 24052" |
| 21:49 |
|
sheenobu |
a lot of our stuff is JMS but our work queue is AMQP |
| 21:49 |
|
whartung |
yea, unless you need some specific capability of AMQP that JMS does not expose |
| 21:49 |
|
sfisque |
aye. jsut like using jpa unless you need a native feature of hibernate/eclipselink/etc. |
| 21:50 |
|
whartung |
Well, I have my openmq cluster running -- now trying to get some client(s) to talk to it so I can break it. |
| 21:50 |
|
sfisque |
deploy some mx beans and you can start pushing buttons via jvisualvm :P |
| 21:51 |
|
sheenobu |
my work is a java shop but my previous jobs that needed RMI and MQ stuff were in ruby/rails where amqp is much more heavily used |
| 21:51 |
|
whartung |
sure |
| 21:51 |
|
whartung |
in all areas Not Java, folks focus on implementations rather than standards and abstractions. |
| 21:51 |
|
whartung |
just truth |
| 21:52 |
|
sheenobu |
*rolls eyes* except that AMQP is still standard =P |
| 21:53 |
|
sheenobu |
I mean I agree with the statement but if you are going to be better-than-thou do it with accurate information |
| 21:53 |
|
whartung |
how did that imply "better than thou"? |
| 21:53 |
|
sfisque |
happesn on our side of the fence too…. "what?! spring remoting isn't a standard?!::!!?!?!?" |
| 21:53 |
|
sfisque |
:P |
| 21:53 |
|
* semiosis |
LOL at JMS being loosely coupled |
| 21:53 |
|
sheenobu |
sfisque: hah nice |
| 21:54 |
|
semiosis |
want loose coupling? send json |
| 21:54 |
|
whartung |
JSON is orthogonal to JMS |
| 21:54 |
|
semiosis |
exactly |
| 21:54 |
|
sfisque |
json is nice, but it's i don't like the loss of typing. |
| 21:55 |
|
sfisque |
it smells of javascript too much |
| 21:55 |
|
sheenobu |
which is icky? =) |
| 21:55 |
|
sfisque |
it "can be". depends on what you're sending |
| 21:55 |
|
semiosis |
one can no longer afford to be anti javascript these days :( |
| 21:55 |
|
sfisque |
there is too much assumption that the "client magically knows" what you're sending |
| 21:56 |
|
whartung |
sure you can! Truth to Power! Question authority! |
| 21:56 |
|
sheenobu |
sfisque: I think some pojo-to-json mappers (like xstream) will preserve types, though the json isn't that human readable |
| 21:56 |
|
whartung |
GO DART!!!111! |
| 21:56 |
|
sfisque |
on a side note, whartung about how long does it take for iana to fulfill an OID request? |
| 21:57 |
|
whartung |
I haven't the slightest idea -- I've never done it. THey probably have someone go through the requests once a week or something. |
| 21:57 |
|
sfisque |
ok, so i shouldnt be chomping at the bit then |
| 21:57 |
|
sfisque |
:-D |
| 21:57 |
|
* sfisque |
taps his foot impatiently |
| 21:58 |
|
whartung |
you should go to the enterprise numbers page, find the last one, and add one to it, and use that until you get yours -- I bets odds are high that's the number you'll get anyway lol |
| 21:59 |
|
sfisque |
:-P |
| 22:02 |
|
sheenobu |
fun chat. excuse me if I made it a bit too inflammatory. |
| 22:02 |
|
whartung |
no worries, it's just that the Java folks like their committees and interfaces, other folks just get work done :) |
| 22:03 |
|
semiosis |
some people say java is overengineered. compared to what? at least it *is* engineered |
| 22:04 |
|
whartung |
heh |
| 23:10 |
|
pdurbin |
javaeebot: lucky xstream java json |
| 23:10 |
|
javaeebot |
pdurbin: http://xstream.codehaus.org/json-tutorial.html |
| 23:11 |
|
pdurbin |
whartung: this might be very useful to me. thanks! |
| 23:12 |
|
whartung |
what might be? |
| 23:12 |
|
whartung |
I mean, "That's great!" |
| 23:12 |
|
pdurbin |
heh. xstream for json :) |
| 23:13 |
|
whartung |
oh, we use GSon for that |
| 23:13 |
|
semiosis |
there are many json (de)serializers |
| 23:13 |
|
pdurbin |
I need to index my pojos into solr or elasticsearch. the latter only takes json as an input format. solr can take xml (and other stuff, csv) |
| 23:13 |
|
whartung |
for "resty" stuff, it's nice, but, yea, it loses all of the classname stuff |
| 23:13 |
|
semiosis |
i'm using MOXy & Jackson in two different projects |
| 23:13 |
|
whartung |
but it seems to work fine for basic beans |
| 23:26 |
|
pdurbin |
I wonder if there's a standard deserializer under javax.json somewhere |
| 23:33 |
|
semiosis |
if you find out, let me know |
| 23:33 |
|
semiosis |
i suspect that package is all API & no impl though |
| 23:35 |
|
sfisque |
i would guess there is a "reference" impl. sun/oracle tend to do that |
| 23:35 |
|
sfisque |
even java.security has bare impls |
