From time to time I come across JavaScript library/framework features, where I ask myself: why do we need this if there is a simple cross-browser solution already?
Y.Lang.isNull(bla) and bla === null look equal to me, while the latter is even more beautiful (same applies for “undefined”).
I don’t like it if there are several ways to do the same, without a single comment in the documentation on top.
I’m porting a pure JavaScript file to YUI, and later maybe to another framework and I’m asking myself: should I touch that line every time to look more framework-ish or just leave it alone? Is there any benefit?
For null or undefined, you should go ahead and use a standard JS check for this.
A slightly longer explanation is here: Y.Lang.isUndefined vs typeof undefined, which is better and why?
At YUI Conf 2012, Ryan Grove gave a presentation When Not to Use YUI.
http://www.youtube.com/watch?v=8cTz73zdDuc
At 8:54 he says "Don't use YUI when vanilla JavaScript will do."
At 9:49 he specifically talks about not using most Y.Lang methods.
At 11:04 he says do not use Y.Lang.isNull.
Somewhere in there he explained that the reason for these methods' existence was for an edge case we would never see, and that the Y.Lang versions are slower than vanilla JavaScript.
At 11:40 he shows a chart on just how much slower. isNull is 48% slower in IE9.
Related
Using JOOQ version 3.13.4
I don't like the ASCII table formatting that the Record.toString() method does.
It's particularly unhelpful in the IDEA debugger view:
But I also don't like dumping needless multi-line strings into my prod logs - which I usually avoid doing; partially for obvious speed/size reasons, but also because they're ugly and hard to read in most log viewer apps (CloudWatch etc.)
I found the Github issue that implemented the ASCII table: https://github.com/jOOQ/jOOQ/issues/1806
I know I can write code to customise this, but I'm wondering if there's a simple flag/config I'm missing to get a simple summary (if I ever got around to writing my own, I'll use JSON)?
The current formatted ASCII table is quite useful for most debugging purposes, which include simple println() calls, Eclipse's debugging view (see below), etc. This includes showing only the first 5 records in a Result for a quick overview, and Record classes work the same.
The feedback from the community has generally been good for these defaults, but if you want to challenge them, try your luck here, and see if your feature request gets community upvotes: https://github.com/jOOQ/jOOQ/issues/new/choose
Eclipse's variable view:
As you can see, with the detail view, it's much less of a problem in Eclipse. I've always found it surprising IntelliJ didn't copy this very useful feature from Eclipse. Maybe, request it?
I know I can write code to customise this
I'll document it here nonetheless, as future visitors will no doubt find this useful.
IntelliJ has a lot of "smartness" in its debugger's variables view, sometimes a bit excessive. For example, an org.jooq.Result just displays its size(), because a Result is a List. I guess it's smart to hedge against excessive efforts if JDK lists are too long, though jOOQ results can handle it, and otherwise it would be possible to display list.subList(0, Math.min(list.size(), 5)) + "...".
Luckily, you can easily specify your own type renderers in IntelliJ, for example this one:
It uses this code to render a jOOQ Record:
formatJSON(new JSONFormat()
.header(false)
.recordFormat(JSONFormat.RecordFormat.OBJECT)
)
The output might look like this:
You might even suggest this as a default to IntelliJ?
but I'm wondering if there's a simple flag/config I'm missing to get a simple summary (if I ever got around to writing my own, I'll use JSON)?
No, there isn't, and I doubt that kind of configurability is reasonable. People will start requesting 100s of flags to get their preferred way of debugging, when in fact, this can be very easily achieved in the IDE as shown above.
Again, you can try your luck with a change request to change it for everyone, but a configuration for this is unlikely to be implemented.
It seems a bit odd to me that events are not structured in Wolkenkit. Coming from the Commanded library in Elixir, one of the first things I did after event-storming was to create my Command and Event types. I understand this is how js traditionally behaves, but just having it just defined in the aggregate will take some getting used to.
"Is it problematic […]?"
Well, this is hard to answer, since it highly depends on your (subjective) definition of problematic. Basically, you already have the answer by yourself:
"I understand this is how js traditionally behaves […]"
That.
To get a better understanding of how commands and events in wolkenkit are structured internally, you might be interested in having a look at the npm module commands-events, which contains the basic data types.
From my very own experience (10 years of C#, 7 years of JavaScript) I can tell you that the missing static type system of JavaScript was never a problem for me, but this is just my highly personal experience.
As you said, it may take some time to get used to it, but you gain an incredible flexibility by this as well.
HTH
Please note that I am one of the developers of wolkenkit, so please take my answer with a grain of salt.
I've heard mixed things about this. I know it's easy when you're stuck to simply enable PHP in the template and hack your way around a problem. However, it almost always introduces potential security issues, and makes a mess of your template to boot.
In most cases where PHP is used, it would be cleaner to write a simple plugin in PHP to achieve what you need.
My question is this: Is it ever acceptable to use PHP inside ExpressionEngine templates? Or is this considered bad practice? If you were a developer who inherited a site I coded, would you cringe if you saw PHP inside templates?
This could just as easily be a question on the merits of eval() and whether it should ever be used. Most of the answers to questions along those lines are equally applicable here.
My view is that enabling PHP in templates is always a Bad Idea. At best, it's not a terrible idea, but there's always a better option. A custom addon will invariably be a better approach, even with seemingly harmless code snippets. I think it's also most likely to be used by those least qualified to use it. Personally, when I started building sites with EE my PHP skills ranged somewhere between 'totally inept' and 'knows enough to be dangerous'. At that time, if I came across a limitation in EE's code I'd often implement a solution via some inline PHP, partly because the idea of developing a custom addon seemed too daunting and partly because clicking a little 'enable PHP' radio button was so simple. Years later, whenever I need to update one of these sites, I definitely do cringe. Here are some of the side effects of PHP in templates:
Potentially introducing serious security vulnerabilities.
Increasing load times, potentially by a lot.
Debugging code becomes harder (good luck figuring out which file/line number has that error).
With tools like Pkg.io you can have the groundwork for an addon in place in 30 seconds. It requires a tiny amount of extra effort, but the gains are well worth it.
Let's imagine I'm answering this question as part of the 80% of people building websites with ExpressionEngine who may consider themselves as designers and or people who have little to no PHP experience:
Is it ever acceptable to use PHP inside ExpressionEngine templates?
No it's not acceptable, please don't do it!
Or is this considered bad practice?
Yup, pretty much.
If you were a developer who inherited a site I coded, would you cringe
if you saw PHP inside templates?
Definitely would cringe and maybe even curse a little.
Okay, now let's imagine I'm answering as part of the 20% who would consider themselves as an EE developer and or who have most experience programming over say designer all day:
Is it ever acceptable to use PHP inside ExpressionEngine templates?
Once in a while it's acceptable. For example you might find a need to turn on PHP for this Stash setup. It really depends on the complexity of what you are trying to achieve. Most things should go into an add-on whenever possible and being "lazy" doesn't count as a time when PHP is acceptable in templates.
Or is this considered bad practice?
ExpressionEngine and Codeigniter for that matter provide a great base to build add-ons and best practices include proper separation when ever possible. This includes separation from PHP and Templates; more often than not.
If it can go into an add-on it should as mentioned before. With that said, there isn't really anything limiting you from using PHP in templates except knowing that this may have security implications, cause future headaches for clients and other devs/designers etc.
If you were a developer who inherited a site I coded, would you cringe
if you saw PHP inside templates?
Definitely wouldn't cringed (unless your PHP was a disaster right from the start) though, would probably question why such simple and even complex code wasn't where it belonged; in an add-on.
Note: I pulled the percents out of thin air though, they quite possibly could be close to reality.
Also note: I realize the use of designer/developer in my answer could be seen as stereotyping though, wasn't quite sure how to avoid it. Hope no one takes offense.
I would consider using something like the phpstringfun add-on. This splits the different, but you're still working in EE tags.
I wouldn't sweat using small amounts of well-documented PHP in templates, but keep it as simple and abstracted as you can.
This may not be for this forum, but...
We write new system and people are used to older system where components are called "modules". So they talk about the accounting module and the auditing module, etc...
This feels very old, like cobol/mainframe talk. What would be better term for functional components in a modern-distributed java system? Would you say the accounting component? The accounting service? Not sure. They refer to the function in the system (and all components behind it) that allow you to perform accounting functions.
If it ain't broke, don't fix it.
The fact that you are asking SO for advice on this suggests that you don't have a better nomenclature ready to use. Spend your time doing something more productive than fretting about this.
I think that "module" is a perfectly reasonable way to refer to a set of functionality. It's still widely used in many languages and frameworks. If it sounds "old" it's only because of your own frame of reference.
Besides, the customer is always right. You should be adopting their verbiage instead of trying to force them to use yours. Do what you want internally but stick with "modules" for the customers' sakes.
Python, a thoroughly modern programming language, has "modules." I don't think there is anything archaic about the word.
If users are used to calling things in the old system "modules," then it will make the new system easier to learn if you use the same terminology.
bundle is the new term ;-) ofcourse coined by OSGI. But when you say bundle then lot of assumptions are made on your code. So whether you want to use this or not is left to you.
I've been evaluating different Java Web Application UI Frameworks. I have about 8 months of intensive JSF experience that I'd like to continue using. JSF also provides me the spider-readable markup as well as the ability to create very simple forms without touching much Java code.
I also will have need for thick-client side interfaces that will perform well with few server round trips. GWT seemed like an ideal choice for this.
So, when I found G4jsf, I thought I had found the best of both worlds. However, I can't seem to find any active development on it. I hope it hasn't died, but it seems like that is the case.
Is there active development on this? Or am I two years too late?
Well, based on the conversation in the reference below, it seems that G4jsf is no longer being supported. If the poster is in fact Sergey Smirnov, I would imagine he'd be a pretty reliable source on the matter. :)
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150674