Днес дойде потвърждение, че концерт на Ciricle II Cirlce наистина ще има. Организаторите са ABV Pro – хората, които стоят зад великолепните концерти на Kamelot и Firewind и бъдещият концерт на Sabaton + HammerFall на 10 април.
Всички искаме това!
Днес дойде потвърждение, че концерт на Ciricle II Cirlce наистина ще има. Организаторите са ABV Pro – хората, които стоят зад великолепните концерти на Kamelot и Firewind и бъдещият концерт на Sabaton + HammerFall на 10 април.
Всички искаме това!
Наложи ми се да пускам SVN сървър под линукс. Не съм гуру, но се оправям. Ето как се прави за Ubuntu за WebDAV ( достъп през http ):
1. Изтеглете subversion и libapache2-svn
sudo apt-get install subversion libapache2-svn
2. Създайте хранилище ( repository )
sudo svnadmin create /svn
3. Направете си групата на апачето да е собственик на хранилището:
sudo chown -R www-data /svn
sudo chmod -R g+rws /svn
4. Отворете конфигурационният файл на webdav модула с любимият си редактор:
sudo nano /etc/apache2/mods-enabled/dav_svn.conf
5. Редактирайте го, така че да се получи:
<Location /svn>
DAV svn
SVNPath /svn
AuthType Basic
AuthName “Can’t touch this!”
AuthUserFile /etc/apache2/dav_svn.passwd
require valid-user
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
6. Направете си парола:
sudo htpasswd2 -cm /etc/apache2/dav_svn.passwd <username>
7. Рестартирайте апача:
sudo /etc/init.d/apache2 restart
8. Вече трябва да имате инсталиран SVN. При мен обаче се получи един проблем: “Could not open the requested SVN filesystem“. Това се оправя така:
8.1 – Копирайте двете библиоетеки: mod_dav_svn.so и mod_authz_svn.so ( ако не може да ги намерите изтеглете си tar.gz архива от http://subversion.tigris.org, разархиврайте и ги вземете от там ) в директорията с модулите на апача: /usr/lib/apache2/modules
Най-сетне преместих блога си на професионален хостинг. Преди използвах за хостинг сървъра на фирмата ни, но той понякога се губеше и беше неприятно. Спрях се на ICDSoft. Надявам се да е добро решение.
Ситуацията е следната – имам няколко обекта, които онаследяват някакъв клас. В родителският клас има методи, които връщат определени суми. При първоначалният ми план, бях направил всеки метод ( три метода ) да си определя сумата с отделна заявка – т.е. три заявки на обект умножени по четири класа т.е. заявките към базата стават дванадесет. Ето примера:
class A {
public function A1() {
// DB Query
}
public function A2() {
// DB Query
}
public function A3() {
// DB Query
}
}
class B extends A {
public function B() {
parent::__construct(); // Задавам нови насройки на базата
}
}
class C extends A {
public function B() {
parent::__construct(); // Задавам нови насройки на базата
}
}
class D extends A {
public function B() {
parent::__construct(); // Задавам нови насройки на базата
}
}
class E extends A {
public function B() {
parent::__construct(); // Задавам нови насройки на базата
}
}
$B = new B();
$B->A1();
$B->A2();
$B->A3();
$C = new C();
$C->A1();
$C->A2();
$C->A3();
$D = new D();
$D->A1();
$D->A2();
$D->A3();
$E = new E();
$E->A1();
$E->A2();
$E->A3();
Така всеки нов обект задава нови настройки за връзка с база данни и използва методие на родитеслкият клас за обработка на получените данни.
До тук добре. Всичко работи, но скоростта опрделено не е оптимизирана. Дванадесет заявки са много. Затова измислих следното решение. Добавих допълнителен метод в родетелският клас, който извлича всичките суми, чрез вътрешни заявки ( sub query / queries ), създава се инициализиращ масив, а останалите методи ще обръщат към него. Да де, ама така излиза, че пак ще се правят 12 заявки, като този път ще са и по-сложни. И да и не. Тук идват на помощ статичните данни. Инициализираме един статичен масив във всеки от дъщерните класове, който ще предваме по референция. При извикването на метода, който извлича всичките данни ще се прави проверка, дали тези данни са вече записани в статичният метод – ако да използваме тях, ако не са – извличаме ги. Ето и примера:
class A {
public function A0( &$arr ) {
if( sizeof( $arr ) == 0 ) {
// Извлечи, обработи и запиши данните в $arr масива
}
return $arr;
}
public function A1() {
$a = $this->A0();
return $a[‘A1Result’];
}
public function A2() {
$a = $this->A0();
return $a[‘A2Result’];
}
public function A3() {
$a = $this->A0();
return $a[‘A3Result’];
}
}
class B extends A {
protected static $arr;
public function B() {
parent::__construct(); // Задавам нови насройки на базата
}
public function A0() {
return parent::A0( &$arr );
}
}
class C extends A {
protected static $arr;
public function B() {
parent::__construct(); // Задавам нови насройки на базата
}
public function A0() {
return parent::A0( &$arr );
}
}
// Тук кодът продължава като първият пример
Ако нещо не сте разбрали или имате предложения – чувствайте се свободни да пишете коментари.
Миналият понеделник във Великобритания промениха процентът на тяхното ДДС ( VAT ), като мярка за справяне с глобалната икономическа криза. От 17.5% го намалиха на 15%. Разбира се, това трябваше да се отрази и в магазините за електронна търговия. Някои от тях просто смениха процента и така цените им с ДДС намаляха, но други решиха да запазят старите си цени като увеличат първоначалната цената, на която се изчислява това ДДС. Ето и една формула за MySQL как се прави това:
UPDATE products SET products_price = products_price + ROUND( ( products_price * 1.175 – products_price * 1.15 ) / 1.15, 2 ) WHERE 1 = 1
Това работи за osCommerce софтуер, но лесно може да го нагодите да работи и за вашата система.
Като работа за последният ми проект, трябваше да интегирам Campaign Monitor ( все го бъркам с Manager ). Това е софтуер за бързо и лесно изпращане на писма до клиенти ( т.е. масово спамене ). За мой лош късмет, точно в момента разработчиците решават, че трябва да внесат промени и премахват примерите ( samples ) и инструментите за работа с API-то им ( API kit ). Логично веднага почнах да търся дали някой добър човечец не е написал подобен клас и след няколко проби през Google попаднах на следния Campaign Monitor клас ( Campaign Monitor class ) написан от Keri Henare ( Кери Хенаре ще го преведа на български ). До тук добре, нали? Проблемът се появи когато видях, че класът е написан за PHP 5, в което няма нищо лошо, стига сървърът, на който е проектът да не беше на PHP 4. Ще кажете “Голям прас. Драсни един handler за PHP5 и всичко ще заспи”. И при други обсоятелства бих се съобразил с вас, но никак не исках да превключвам версията на сървъра, защото проектът не съм го писал изцяло аз, а е доста посещаван сайт и не знам откъде може да изкочи проблем ).
Затова реших да преправя класът от PHP5 към PHP4. След като разкарах private, public, protected декларациите за функции и данни, след като премахнах статичните извиквания или добавих обекти за тях се заех с функционалността. Буднах малко тук, малко там … и в крайна сметка се оказа, че трябва да бутна мнооого сериозно по функцията за превръщане на XML към Array ( XML to Array ). Бе направо я изтрих и я написах отново, само че да работи за PHP4.
И тук дойде другата ми изненада. domxml_open_mem фунцкията не съществува в PHP5!? Защо сте я махнали, бре? На кого му пречеше? Това е проблем, защото знам ли кога hosting компанията ще реши масово да премине на PHP5 ( а защо не го е направила до сега? ) и трябваше да си подсигуря стабилността ( сравнително ) на моята работа и на PHP5. Тук за пореден път много полезен се оказа Google. Оказа се, че фунцкиите за DOMXML ги има написани на PHP, а не за PHP. Copy/paste, една проверка дали е PHP 5, малко тестове на PHP5 сървър и съм готов.
Вдъхновен от Open Source движението реших да публикувам PHP4 версията на Campaign Monitor класът, както и съпровождащият го клас за правилна работа с XML на PHP5.
Campaign Monitor for PHP4 including Dom-xml-php4-to-php5
Не вярвам на някой да му потрябва, но знае ли човек ….
2 ден – Метрата ще се наводнят от изходните води.
7-ден – Ядрените реактори ще спрат да се охлаждат.
1 година – В света ще оцелеят повече от 10 милиона птици. Съобщителните и токовите кули ще се разпаднат. Градовете ще се напълнят с животни.
3 години – Течовете от газовите тръби ще станат причина за пожари и взривове. Структурите на сградите ще станат нестабилни. Поради липса на топлина в тях ще изчезнат хлебарките.
10 години – Покривите на повечето сгради ще се разпаднат в резултат на корозия и взаимодействие на различни химични елементи.
20 години– Всички железни постройки ще почнат да се разрушават. Ще изчезне и Панамския канал.
100 години – Популацията на слоновете ще се увеличи повече от 20 пъти. Малките хищници, като например лисиците ще са на ръба на изчезване, поради появата на друг техен конкурент-домашните котки.
300 години – Голяма част от масивните мостове ще рухнат.
Стените на много язовири ще рухнат, поради липса на поддръжка.
В резултат на това много градове ще бъдат наводнени.


500 години– Останките от градовете ще бъдат завладяни от обилна растителност.

15 000 години – Повечето градове ще отстъпят пред появата на ледников период. Единственото, което ще остане сравнително цяло, това ще бъдат повечето подземни конструкции.
35 000 години – Веществата, които замърсяват околната среда още от времето на човека най-накрая ще се абсорбират. Но пълното пречистване от кадмий например, ще отнеме още 75 000 години.
100 000 години – Нивото на въглероден диоксид в атмосферата ще се върне към това, което е било преди появата на човека.
250 000 години – Радиацията,породена от експлозии на атомни бомби и радиацията в Чернобил, ще спрат да бъдат опасни.
2 000 000 години – Възможно е някои животни да добият способност да разлагат пластмасовите изделия и да ги ядат.
8 500 000 години – Останките от някои архитектурни обекти като паметници и сгради все още ще се разпознават, ако не са били разрушени от земетресенията.
3 милиарда години – На Земята все още ще съществува живот, но такъв какъвто едва ли можем да си представим.
6,5 милиарда години – Земята ще се стопи под влияние на Слънцето, което вече ще е погълнало някои планети-неизбежния край на Земята.
Вечност – Останките от спътниците ще продължават да обикалят Космоса като единствена следа от съществуването на човека.
Можете да прочетете оригиналът на статията както и да видите повече снимки в блога “Бикинимедия”.
За един много завъртян CSS проект ми се наложи да потърся css hack само за Safari. И преди съм търсил, но винаги съм намирал такива, които вече не работят към текущата версия на Safari. Днес обаче докато търсех, забелязах, че датите на всичките статии/уроци, които намирам са доста стари ( 2005, 2006 година ). Тогава се сетих за статията, която четох в блога на Ему – Филтрация по последен период в Google и с идеята, че това ще ми помогне реших да го използвам. И наистина още при първото търсене за “safari css hack” за последните 2 месеца попаднах на тази статия – http://themechanism.com/blog/2008/01/08/safari-css-hack-redux/
Самият хак е следният.
@media screen and (-webkit-min-device-pixel-ratio:0) {
// Тук пишете каквото искате да се вижда само под Safari и Opera 9;
}
Според автора на статията, този хак най-вероятно ще остане за вбъдеще понеже -webkit часта от него най-вероятно няма да бъде използвана от останалите конкуренти на Safari.