In the singularity demo, there are a few samples using a push and pull mixin. When used they adjust content placement across the gutter. Looking high and low, I could not find any documented reference to these mixins. Are they part of the long term feature set or a leftover? If not, what is the recommended way to do this sort of gutter shift?
Found the answer here
Push/Pull are currently non-documented features that are being deprecated in Singularity 1.2.0. They make sense when using float output method and symmetric grids, but don't make sense for any other combination we can think of. Instead, we recommend utilizing the isolation output style (or, if you're feeling adventurous, the new calc output style in Singularity Extras)
The other option is to write your own mixin with the use of the grid-span, column-span, and gutter-span functions.
Having read about the deprecation of push/pull in Ver 1.2.0, I have just swapped my pull spans for isolation spans. It was so easy, I can't imagine why I hadn't used that method before. A lot of Singularitygs has to be learnt by trial and error, but perhaps the next set of docs will be better. I have also seen that they are removing the grid-overlay and grid-toggle from Ver 1.2.0. That's a shame. I got them working beautifully despite the lack of documentation. Still, the background-grid works well.
Related
We use SonarQube against our application. One of the SonarQube rules says:
Selectors of lower specificity should come before overriding selectors of higher specificity
The details are here. As my application has many violations, changing the order by hand isn't really feasible. I'm wondering if there's a way to use scss-lint, stylelint or something else in a "fix" mode that could change the order of the selectors. I looked but couldn't find anything in stylelint. Maybe it can't safely be done automatically, as changing the order could affect specificity and therefore change the application behaviour...
As I personal! know there is no Linter which provide that. (I am curious about it.) But just some thoughts about the need of following that 'rule':
Indeed: writing SASS/CSS the way Selectors with lower specifity comes first is a good practicse. The CSS structure becomes more readable and it is easier to build up your code structure as there is a clearer systematic in your head (and the code).
But just up from the mechanic CSS works there is REALLY NO NEED to do it this way. The code simply doesn't become safer doing so or less safe and the pages don't load slower not doing it. That is what the mechanic of specifity has been done for: as of the specifity not the order of the selectors counts and you are able to write your code in the order you need it. Only if the specifity is the same the order counts.
So, maybe this rule leads to 'better' code. But: NOT ALL RULES NEEDS TO BE FULLFILLED. Not all rules Google tries to establish with their best practice rules they offer in their browser, nor all rules other analysis tools provide needs to be followed.
And if not in this project as it needs resources to correct it ... it maybe could but has not be a target for next project ;-)
I want to find an image in another image. I already tried a "template matching" approach, but i didn't know how make it invariant to changes in scale, rotation, perspective, etc.
I have read about feature detection and suspect that usage of sift-features might be the best approach. Beside that i need an implementation of using feature detection using javacv not opencv.
Is there any implementation using feature detection or any other proposal for my problem?
If you understand the basics of JavaCV you can look at the ObjectFinder example of JavaCV.
ObjectFinder # code.google.com
This example shows you, how to do the important steps to solve your problem.
Before using the ObjectFinder you have to call the following method to load the non free modules (e.g. SURF):
com.googlecode.javacv.cpp.opencv_nonfree.initModule_nonfree();
Just for completeness. You can use the image feature matching capabilities provided by opencv, described here. There is even a full implementation of a well working matcher with javacv (in scala though, but it's easily portable into java).
I would like to know if the following is possible in Scala (but I think the question can be applied also to Java):
Create a Scala file dynamically (ok, no problem here)
Compile it (I don't think this would be a real problem)
Load/Unload the new class dynamically
Aside from knowing if dynamic code loading/reloading is possible (it's possible in Java so I think it's feasible also in Scala) I would like also to know the implication of this in terms of performance degradation (I could have many many classes, with no name clash but really many of them!).
TIA!
P.S.: I know other questions about class loading in Scala exist, but I haven't been able to find an answer about performance!
Yes, everything you want to do is certainly possible. You might like to take a look at ScalaMock, which is an example of creating Scala source code dynamically. And at SBT which is an example of calling the compiler from code. And then there are many different systems that load classes dynamically - look at the documentation for loadLibrary as a starting point.
But, depending on what you want to achieve, you might like to look at Scala Macros instead. They provide the same kind of flexibility as you would get by generating source code and then compiling it, but without many of the downsides of that approach. The original version of ScalaMock used to work by generating source code, but I'm in the process of moving to using macros instead.
It's all possible in Scala, as is clearly demonstrated by the REPL. It's even going to be relatively easy with Scala 2.10.
In Ruby, there are currently 3 ODM (object data mappers) maintained:
MongoMapper
Mongoid
MongoDoc
Which is your preferred and why?
I just chose Mongoid for a new Rails 3 project based on the argument that it has the best documentation.
Since I am new to MongoDB (with many years of MySQL and a little bit of CouchDB experience), I needed good guides that take me by the hand and help me deliver something working within a reasonable span of time.
AFAIK Mongoid has just that: a nice looking site, with well documented guides for newbies like me.
Code Stats for Mongoid and MongoMapper
It looks like MongoMapper has much better code quality (if it does the same with less).
Here's the analyzer CodeStats https://github.com/alexeypetrushin/code_stats
In my opinion it's hard to say which is better, if you have DataMapper experience you'll like MongoMapper, but if you used ActiveRecord, Mongoid it's your preferred choice. I believe all of them worths a try concerning the context where you want to use them.
I am using MongoMapper. It good except it is little slow with Time conversions.
And it loads all data as Array. MyCollection.all for example gives you huge array, not cursor.
while Mongoid says: - Optimized for use with extremely large datasets.
So I guess you could try MongoID if you need speed and have big recordsets.
I was trying MongoMapper, but I think I'll go with Mongoid, because after quick reading docs it seems to me somewhat easier. Plus, it's developed by guys from Hashrocket, so that's a good reason itself.
While not a direct answer to your question, I would also consider using the basic ruby driver directly. Unlike the various SQL adapters out there Mongo's ruby class is easy to use and powerful. Because queries are hashes, composing queries is generally easy. The real advantage is access to the Atomic Modifiers. If you benefit from a Document database, these modifiers should be in your toolbox.
Having said this, I will go ahead and recommend MongoMapper because it has cleaner integration with the non-CRUD parts of MongoDB. Both projects are making gains in this area, and the situation may have changes since I did my research in December 2010.
I can recommend MongoMapper, since it also works with rails3 (beta and master). I personally didn't try the other 2 mappers you mentioned, since MM works great in my workflow and the mailinglist is very active. Furthermore the codebase is really stable and the only issue is with rails3 master, so you should use fredwu's branch, which already includes fixes for the current rails3 master changes on form_for: http://github.com/fredwu/mongomapper.git
There's also MongodbModel http://alexeypetrushin.github.com/mongodb_model
What are the things you wish Ruby (and more generally the Ruby community) would improve?
I read somewhere that Ruby is the love-child of Smalltalk and LISP, with Miss Perl as the Nanny.
I have a lot of respect for Ruby's parents, but I'm not sure I like the influence Miss Perl had on the child. Specifically, I don't like the predefined variables: I need a cheat sheet to know what they mean. You could say "just don't use them". Well, I don't... but other people do. And when I download a plugin on the Web, I have no choice but to fetch my cheat-sheet if I ever need to go and touch the source code. I just wish they would remove those from the language itself.
Also, I think that Ruby is too much of a moving target. My code breaks on every new Ruby upgrade, even on minor releases. This is true also of Ruby on Rails and most Rails plugins I have worked with: they just change all the time, and nobody seems to care whether the changes break everything or not. IMHO, although I love a lot of things in Ruby, this lack of stability is almost a show-stopper.
I wish people would consider backward compatibility between minor releases as an unbreakable rule when releasing a new language (or library or framework) version.
I wish that some of the lesser used modules of the standard library were documented.
Make require-ing files less painful. Don't ask me how, but maybe have one file dedicated to knowing the paths involved and just get rid of the relative path crud from everything else.
Getting rid of the artificial distinction between Modules and Classes would be nice.
Both Modules and Classes are Namespaces. Modules are also Mixins, while Classes aren't. Classes can also be instantiated while Modules can't. This distinction is unnecessary. Just get rid of Modules and allow Classes to be used as Mixins.
An example of a language where this works is Newspeak.
I'd appreciate being able to install ruby 1.9 as an RPM rather than having to use the source.
Make Ruby completely Message Sending based, get rid of everything that is not a message send: local variables, global variables, instance variables, class hierarchy variables, constants, magic globals, magic constants, builtin operators, builtin keywords, even literals. See Self, Ioke or Newspeak for the incredible power and elegance this gains.
I wish they would get rid of the predefined variables: $!, $&, $+, etc.
I would like to have support for static compile-time metaprogramming. The Converge Programming Language might be a good starting point.
Replace the Mixin system with a Traits system.
Replace Exceptions with a Common Lisp style Conditions system.