Comments for Dmytro Shteflyuk's Home

Comment on CodeColorer by Dmytro Shteflyuk

Dmytro Shteflyuk — Sun, 21 Feb 2010 12:34:00 +0000

I don’t like Geshi line numbers because when you copy code, browser copies them too. It’s really weird thing, so I ended up with this table implementation. Your point about 100% makes sense, I’ll take a look how it will impact code blocks layout.

Comment on CodeColorer by Douglas

Douglas — Sun, 21 Feb 2010 05:57:00 +0000

Hi. There is a problem in your code that appear when yout set an image as background. To verify that creates a “stripe” image (www.stripegenerator.com) and add it as background (in codecolorer.css ) and you will see a continuity break (set the width as 100% in the plugin options). I searched in the code and I saw that the cause is the way that you show the line numbers. You calculate the numbers manually and create a table to show them. So there is a conflict between the end of the table and the rest of the container that you create to apply the user options. I solved in two ways. The simplest is to put a width=”100%” in your second , so the table will fill all the container space.
The second is to use the Geshi methods to show the lines:

1 2	$geshi->start_line_numbers_at($options['first_line']); $geshi->enable_line_numbers(GESHI_FANCY_LINE_NUMBERS);

deleting the creation of the table.

thanks.

Comment on CodeColorer by Deimos

Deimos — Sun, 21 Feb 2010 15:25:00 +0000

странно у вас не появилась ошибка, у меня пишет:

1	GeSHi Error: GeSHi could not find the language (using path /wp-content/plugins/codecolorer/lib/geshi/) (code 2)

Comment on CodeColorer by Deimos

Deimos — Sun, 21 Feb 2010 15:23:00 +0000

Добрый день, подскажите как то можно сделать чтобы когда человек вводит
{code lang=”"}тут текст{code} (специально заменил)
не вылазила ошибка, вот такая:

1	<code>тут текст<code>

У меня стоит последняя 0.9.7 версия, версия WordPress 2.7.1

Comment on CodeColorer by Tsalagi

Tsalagi — Sun, 21 Feb 2010 05:12:00 +0000

Try again.
1. When I use no_cc="true" my text is removed from my page.

Comment on CodeColorer by Tsalagi

Tsalagi — Sun, 21 Feb 2010 05:10:00 +0000

Is this plugin supported on this website. If so I need some solutions to two issues.
1. When I use <code> it removes my text from my page.
2. When I set a theme I still get no colors on the code on my page.

Thanks in advance.

Comment on CodeColorer by IgorKa - Информационный ресурс » Wordpress - подсветка кода

IgorKa - Информационный ресурс » Wordpress - подсветка кода — Sun, 21 Feb 2010 18:56:00 +0000

[...] на codecolorer. Прочесть об этом плагине рекомендую на странице автора. В общем пока остановился на этом плагине, так [...]

Comment on CodeColorer by Dmytro Shteflyuk

Dmytro Shteflyuk — Sun, 21 Feb 2010 17:30:00 +0000

You can do it using first_line option:

3	$butnotme = 2;

Comment on My top 7 RSpec best practices by Dmytro Shteflyuk

Dmytro Shteflyuk — Sun, 21 Feb 2010 00:23:00 +0000

Hey Myron, thank you for the reply. I have updated an article with more consistent context usage, it was my failure.

About mocking in controllers, yes it makes sense. Sometimes. When you pretty sure you models work as expected, when you confident in their work. As I said, in some circumstances you can get false positives, for example, when add after_create hook which fails with an exception, or new super-useful NOT NULL restriction on one of columns in the database. If you have all your models covered with — it’s ok, use mocks to get controller specs clean in simple. By the way, did you hear about stub_model?

Comment on My top 7 RSpec best practices by Myron

Myron — Sun, 21 Feb 2010 19:44:00 +0000

These are some good tips, but I don’t fully agree with all them. Particular points 4 and 5:

About mocks: In general, I agree with you that over mocking is a problem. But I disagree that it’s always better to use no mocking or stubbing in your controller specs. In my opinion, the danger of mocking is directly proportional to how likely it is the interface you are mocking will change. So, mocking a class method that frequently changes its interface is dangerous and should be avoided. Mocking an interface that is highly unlikely to change is generally safe and can lead to less brittle tests.

So, for example, when I’m spec’ing the #update and #create actions of a controller, I mock #valid? so that it returns true or false based on which code path I want to test. The alternative is to pass valid or invalid attributes in the request, but this leads to fragile specs: now my controller specs have to know what attribute values are valid and invalid, and when my model validation logic changes, my controller specs begin to fail. Really, I don’t care in my controller specs what is valid and invalid…I just care that when the attributes are valid, it does one thing, and when they are invalid, it does another thing. #valid? has been around in ActiveRecord for as long as I can remember (I imagine it was there from the first release) and the likely hood of that interface ever changing is approximately nil. I think it’s safe and useful to use mocking here.

About describe vs. context: In your example, you use context for both “.top” and “when just created”. I think context is appropriate for the latter (since “when just created” describes a context the examples run in) but describe is more appropriate for the former. “.top” isn’t a context; rather it’s simply grouping all the examples where you are describing the top method. I use use describe in these cases since you’re describing the behavior of a method.