Simple question, just no luck on Google.
I was wondering it there is a difference in using
Zend_Controller_Request_Http::setBaseUrl(); and Zend_Controller_Request_Http::setBaseUrl('');
It seemed to me that using Zend_Controller_Request_Http::setBaseUrl('') could be seen as accident prone later on, correct me if I'm wrong.
The end result is the same. Rather than worrying about which one to use, just don't set a base URL if you don't have one.
Related
I'm not sure this question should be asked here, but I don't know where else, so I hope it is not banned. And if it is, please address me to a place where it should be asked.
I know in Laravel you can pass a variable called "Bar" to a view like this:
view()->withBar('Foo');
but I don't know how do I know, and the most important, where is it 'officially' explained.
I can find it in the __call function in the code (https://github.com/laravel/framework/blob/5.4/src/Illuminate/View/View.php) but not in the official API.
So, where is it officially explained?
This use to be documented but it has hasn't been included in the docs since 5.0 https://laravel.com/docs/5.0/views#passing-data-to-views.
As with most things with Laravel there are usually a few different ways to do the exact same thing so (for whatever reason) somethings do eventually get omitted from the docs but the functionality doesn't get removed. I would imagine this is because it might be considered a bad practice or not the best approach or even that Taylor may eventually want to remove it...who knows. Either way, there is usually an alternative given to achieve the same outcome.
Hope this helps!
I'd like to know what suggestions there are for Googling (or using other search engines if preferable) for Ruby syntax. I'm very new, and a substantial part of my baptism by fire comes by way of reading other people's code. Ruby in particular can be challenging this way-- it's fantastically compact and easy to read if you know how to read it, so to speak. But figuring that out can be difficult at times. It's worth it, but difficult. So, for example, let's say I encounter an expression like this:
tquery = "#{MASTER_URL}#{query_str}"
Well, apparently there's something going on with the syntax #{stuff}, but what? A variable being manipulated, it seems? If you encountered such an expression and didn't know about interpolation/substitution and have no ready access to someone to ask directly, how would you go about Googling that? That's just an example, of course, but I hope it illustrates the type of problem I'd like to address.
Also, if there are better tags to apply to this post please let me know and I will add. Thank you.
Symbolhound is pretty good for this. For example, here's the search for Ruby's #{}.
Mind, as you can see from the results, it doesn't necessarily come immediately back and tell you what the notation you searched for is named, or how it's defined, but it does return some helpful results to get you started. It's especially useful for punctuation-based syntax elements that are difficult or impossible to search for in other search engines.
I am working through the Sassdash Library, and there are numerous functions that use a argument $this-arg. I am having a lot of trouble understanding what it does. Can anyone simply explain what this does and what some simple use cases might be?
It is similar to how this works in JS.
I see that some programmers add code that, after all, does not do anything useful. For instance (C#):
[Serializable]
class Foo {
// ...
string SerializeMe() {
return new XmlSerializer(typeof(this)).Serialize(this).ToString(); // serialize to xml (syntax wrong, not important here)
}
}
The class is marked as Serializable, but the only way it is serialized is by means of XmlSerialization, which does not require that class attribute at all.
I personally hate this kind of useless code, but I see it quite often and I'm curious as to what others think about it. Is this not so serious a flaw after all? Is it common practice in the industry? Or is this just plain bad and should be removed no matter what?
Good Source Control means that useless code or code that is no longer required should be removed. It can always be retrieved from the source control at a later date.
My rule of thumb,
If its not used get rid of it.
All surplus comments, attrributes are just noise and help your code to become unreadable. If left there they encourage more surplus code in your code base. So remove it.
I try to follow the YAGNI principle, so this bothers me as well.
Does it take even a minimal effort to read that additional (useless, as you added) code?
If yes (and I think it is so) then it should not be in the code. Code like this is polluted with extra snippets that are not useful, they are there "just in case".
The "later on refactoring" of these things can be painful, after 6 o 12 months, who is going to remember if that was really used?
Really don't like it.
Because I then spend valuable time trying to figure out why it's there. Assuming that if it's there, it's there for a reason, and if I don't see the reason, then there's a chance I'm missing something important that I should understand before I start messing with the code. It irritates me when I realize that I've just wasted an hour trying to understand why, or what, some snippet of code is doing, that was just left there by some developer too lazy to go back and remove it.
Useless one-liner code can and should be removed.
Useless code that took time to write can and should be removed...but people in charge tend to get queasy about this. Perhaps the best solution is to have a ProbablyUselessButWhoKnows project where everyone can check in pointless code that might be used again in two or three years. If nothing else, this way people don't have to feel nervous about deleting it.
(Yes, in theory you can get it out of source control, but old deleted code in source control is not exactly highly discoverable.)
In a commercial project - I'd say no, especially if someone can de-assemble it for reading and then has a WTF moment.
In a home-project - sure why not, I often keep some snippets for later use.
Well I can't comment this particular piece of code without knowing your background but I personally follow strictly a rule not to have anything in code unless I really need it. Or at least know that it may be useful some day for something I have in mind already now.
This is bad code.
Bad code is common practice.
That being said sometimes it is not worth the effort in changing stuff that isn't "broken".
It would seem that perfection is attained not when no more can be added, but when no more can be removed. — Antoine de Saint-Exupéry
Is think the meaning of useless is that it cannot and will not be used. I also think that an open door is very open.
If there is an active plan to use this additional feature, then keep it in.
If you know it will never be used, or if that plan stopped being relevant 6 months ago, then pull it out. I'd comment it out first, then remove it fully later.
I'm in the midst of rescoping a lot of variables that were public but really only need to be protected or private, simply because they don't make sense from an API perspective to be exposed--that and nothing uses them.
When adding internationalisation capabilities to an Oracle web application (build on mod_plsql), I'd like to interpret the HTTP_ACCEPT_LANGUAGE parameter and use it to set various NLS_* settings in the Oracle session.
For example:
HTTP_ACCEPT_LANGUAGE=de
alter session set nls_territory=germany;
alter session set nls_lang=...
However, you could get something more complicated I suppose...
HTTP_ACCEPT_LANGUAGE=en-us,en;q=0.5
How have folks tackled this sort of thing before?
EDIT - following on from Curt's detailed answer below
Thanks for the clear and detailed reply Curt. I didn't really make myself clear though, as I was really asking if there were any existing Oracle widgets that handled this.
I'm already down the road of manually parsing the HTTP_ACCEPT_LANGUAGE variable and - as Curt indicated in his answer - there are a few subtle areas of complexity. It feels like something that must have been done many times before. As I wrote more and more code I had that sinking "I'm reinventing the wheel" feeling. :)
There must be an existing Oracle approach for this - probably something in iAS??
EDIT - stumbled across the answer
While looking for something else, I stumbled across the UTL_I18N package, which does exactly wham I'm after:
Is there an easy way to convert HTTP_ACCEPT_LANGUAGE to Oracle NLS_LANG settings?
Sure, and it's not too tough, if you break up the problem properly and don't get to ambitious at first.
You need, essentially, two functions: one to parse the HTTP_ACCEPT_LANGUAGE and produce a language code, and one to take that and generate the appropriate set commands.
The former can get pretty sophisticated; if you're given only 'en', you probably want to generate 'en-us', you need to deal with chosing one of multiple choices when nothing matches perfectly, you need to deal with malformed header values, and so on. Don't try to tackle this all at once: just do something very simple at first, and extend it later.
The same more or less goes for the other half of it, generating the set commands, but this is pretty simple in and of itself anyway; it's really just a lookup function, though it may get a bit more sophisticated depending on what is provided to it.
What will really make or break your programming experience on something like this is your unit tests. This is an ideal problem for unit testing and test-driven development. Unit tests will make sure that when you change things, old functionality keeps working, and make it easier to add new functionality and fix bugs, because you just add another test and you have that to guide you from that point on. (You'll also find it easier to do a complete rewrite of one of the functions if you find out you've gone terribly wrong at some point, because you can easily confirm that the new version isn't breaking anything.)
How you do unit testing in your environment is probably a bit beyond the scope of this question, but let me add a few hints. First, if there's a unit test framework ("pl-sql-unit?") available for your environment, that's great. If not, don't panic. You don't need anything sophisticated: just a set of inputs and expected outputs, and a way to run them through the function and either say "all OK!" or show any incorrect results. You can probably write a single, simple PL/SQL function that reads the inputs and expected outputs from a table and does this for you.
Finally stumbled across the answer. The Oracle package UTL_I18N contains functions to map from the browser language codes to Oracle NLS settings:
utl_i18n.map_language_from_iso;
utl_i18n.map_territory_from_iso;
The mapping doesn't seem to cope very well with multi-language settings, e.g. en-us,en;q=0.5, but as long as you just use the first 5 characters the functions seem to work ok.
HTTP_ACCEPT_LANGUAGE: ar-lb,en-gb;q=0.5
v_language:
v_territory:
HTTP_ACCEPT_LANGUAGE: ar-lb
v_language: ARABIC
v_territory: LEBANON