Google search linkek

Régen minden jobb volt. A google kereső oldalán linkek voltak, az ember keresett, talált, linkre kattintott, vagy másolt… Most meg? A google a találatokat saját borzasztó google linkekkel jeleníti meg, így méri ki mit csinál a találatokkal. Ezzel nem is lenne nagy baj, addig amíg az ember mondjuk nem egy olyan dolgot talál meg, ami nem honlap. Az ugyanis megnyílik, de google linkből soha nem lesz normális link…

Keressetek csak arra, hogy: cubase .pdf

Aztán próbáljátok meg kitalálni, hogy a pdf hol is van.

És jönnek a hackelések:

– ha rövid a link (szerencse) akkor ki lehet másolni a link alatti zöld részből. Ha hosszú az balszerencse, mert a google kipontozza:

ftp://ftp.steinberg.net/…/Cubase_4/Docs…/Operation_Manual.p…    oh jeah…

– a böngésző kiírja ha a link fölé állsz (jobb/bal alul) az elérést… leírhatod ezt pl. egy papírra (de ez nem valami 21. századi megoldás)

ha kimásolod a linket, ezt kapod:

http://www.google.hu/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja
&ved=0CCwQFjAA&url=ftp%3A%2%2Fftp.steinberg.net%2FDownload
%2FCubase_4%2FDocs_English%2FOperation_Manual.pdf
&ei=SjclUbSxOY6Sswbj6oHQCA&
usg=AFQjCNHVXqjWEqwRx0jd9jEfU8qLHaO3fw
&sig2=-vlLvtxhVOM_8yTbNzge0w&bvm=bv.42661473,d.d2k

Benne van az url, de természetesen az encoding miatt ezt böngésző nem nyitja meg… Átírhatod kézzel a %2F és egyéb %-os karaktereket…

– letöltés után a downloads-ban a felugró menüben van egy copy download link (de ehhez előtte le kell tölteni a fájlt)

– ha van down them all kiegészítő telepítve, akkor azzal kell menteni a fájlt, az kiírja a linket, és refering page-ban megjeleníti a google-s szemetet

– van egy oldal is ami ezt a problémát orvosolja: http://george.vps.websupport.sk/google/

Most mondanám, hogy a bing-ben ez jól működik (tényleg) csak az sajnos a cubase .pdf keresésre közel sem ad olyan releváns találatot mint a google… Egyszer össze kellene ülniük, egy közös meetingre a keresős srácoknak, és csinálni egy jót, ami használható…

Ubuntu – utf8 hu locale

Ha szeretnénk ékezetes karaktereket látni (beleértve a nagyon bonyolult ő betűt is) akkor az alábbiakat kell tenni:

1. felvenni a locale beállításokat a támogatott locale beállítások közé:

echo ‘hu_HU.UTF-8 UTF-8’ | sudo tee -a /var/lib/locales/supported.d/hu

2. újra generálni a locale fájlokat

sudo dpkg-reconfigure locales

3. beállítani ezt defaultnak:

sudo nano /etc/default/locale

Ebbe kell beírni az alábbi két sort:

LANG=hu_HU.UTF-8
LC_ALL=hu_HU.UTF-8

4. puty-al is megértetni, hogy itt bizony utf-8 lesz

Window – Translation – Recieved data ssumed to -> UTF-8

Tadamm…

jar fájl futtatása windows alól

Egy ideig működött, majd nem… A megoldás:

Open up an administrator command window (this is needed if you’re using Vista or Windows 7 with UAC enabled) and do:

assoc .jar=jarfileterm
ftype jarfileterm=”C:\Program Files\Java\jre7\bin\java.exe” -jar “%1” %*

In your case, you should replace the C:\Program Files\Java\jre7\bin\java.exe path with the one for your install of the jre.

Forrás: http://stackoverflow.com/questions/10446986/double-clicking-jar-file-does-not-open-command-prompt

Music selector v0.1

Elmondható, hogy mostanában csak blogokról hallgatok zenét, abból viszont viszonylag sokat. Egy idő után kezdtem belekavarodni, hogy honnan, mit hallottam, mit nem. Azt hittem más is találkozott már ezzel a problémával, biztos van erre valami jó megoldás.

A rossz hír, hogy jó megoldást nem találtam (legalábbis olyan ami az én elvárásaimnak megfelel). A jó hír, hogy írtam egyet.

Sajnos nem volt annyi időm mint rá mint a synctocloud-ra (egy estét terveztem be rá, amihez tartottam is magam), így egyenlőre ez a verzió csak belső használatra készült, de ha lesz rá igény, akkor (picit átdolgozva) még akár publicitást is nyerhet (bár nem tudom, hogy az érintett blogok üzemeltetői ehhez mit szólnának :).

WordPress popup dialog

A wordpress pont olyan nekem a honlapoknál mint a lokalizáció a programoknál. Általában mindig úgy indul a dolog, hogy felesleges, ez csak egy egyszerű valami lesz, és a végére (mondjuk pár év fejlesztés után) kiderül, hogy mégis csak kell, és megkerülhetetlen. Személy szerint már a hello world honlapot is csak wordpress alá telepíteném, mert előbb utóbb biztos kiderül, hogy kellene bele még egy két dolog, és aztán meg lehet szívni a migrálással.

A wordpress önmagában is egy jó választás, minőségi átlátható kód, stb.

De mi is kell a jquery ui használatához? Egy plugin, aminek meglepő módon jQuery UI Widgets.

Ezek után már lehet standard módon használni a dialógus ablakot:

jQuery(document).ready( function(){
 jQuery('#blood_1').click(function() {
  jQuery('#blood_1_details').dialog({modal: true,title:'blood_1 details'});
 });
});

 

<a id="blood_1" href="#invalid">details</a>
<div id='blood_1_details' style='display:none;'>Game WASD+Mouse cfg...</div>

A javascriptet betölthetjük külön is a Specific CSS/JS for Posts and Pages plugin segítségével, és ha nem akarjuk ezeket a dolgokat hard code-olni az oldalunkba, akkor használhatjuk a php include-okat is az Exec-PHP plugin segítségével.

Ubuntu költöztetése új merevlemezre

Vége a kampánynak, lassan újraéled a blog is. Most, hogy az éjjel nappal tartó munkának vége, és  szerverbe tökéletes lesz a 32gb-os ssd, de tévedtem, így pont amire minden összeállt, túrhatom szét a meglévő telepítést. Pontosabban ez lenne a helyzet ha windows szerverem lenne (már vagy 12x telepítettem volna újra), de mivel ez linux, viszonylag egyszerű a dolog.

1. Első körben hozzunk létre partíciókat az új lemezen (ajánlott a GParted erre a célra). Arra kell csak figyelni, hogy azonos típusúak legyenek. Nálam így nézett ki:

  • Primary – ext4
  • Extended – swap

Az új primary partíciót tegyük bootable-vá (Manage Flags – boot legyen kipipálva). Érdemes adni labelt is az új partíciónak (pl.: diskname), így könnyebb lesz megtalálni

2. Mountoljuk fel az új partíciónkat, pl. ide:  /media/diskname (szégyen gyalázat, én rá szoktam nyomni a lemez nevére, a grafikus felületen, és az mountolja jól)

3. Ha ezzel megvagyunk, akkor root-ként másoljuk át az összes fájlt:

cp -ax / /media/diskname

4. A fájlok a helyükön, javítanunk kell az fstab bejegyzéseket, itt a régi disk uuid-et ki kell cserélni az újra (a diskuuid-eket a blkid parancs segítségével tudjuk kilistázni). Az fstab értelemszerűen a /media/diskname/etc/fstab helyen van…

5. kell telepítenünk egy grub-ot, hogy legyen valami a boot sectorba (itt az sdb az új lemez).

sudo grub-install --root-directory=/media/diskname /dev/sdb

Elviekben kész vagyunk. Az új boot után a dropbox-ot újra hozzá kell rendelni az account-unkhoz, mert ő a merevlemezlemez paramétereit veszi figyelembe a kulcsképzés során, így az új lemezzel új dropbox session kulcsunk is lesz.

Ha valaki a meglévő gépe mellé szeretné az újat, akkor érdemes még pár dolgot átírni:

A rendszer neve:

nano /media/diskname/etc/hostname

Régi ssh kulcs:

rm /media/diskname/etc/ssh/ssh_host_*_key*

(az új bootolás során újra kell generálni az ssh kulcsot: dpkg-reconfigure openssh-server)

Hálózati beállítások (ha valaki stat ip-t használ)

nano /media/diskname/etc/network/interfaces

Linux es a media

Egy kissebb hardware upgrade utan (intel d2700mud) ujra mukodik a szerverem.

Mar mukodik rajta a letfontossagu dolgok, mint a plex media server, az openvpn, stb.

Viszont komoly problemat jelntett, hogy a plex szervernek symlinkelt zenek kozott akadtak flac fajok, amit bizonyos eszkozok (pl csoda android) nem tamogat.

El is kezdtem konvertalni a flac fajlokat mp3-ba, de a konvertalas alatt ratalaltam az mp3fs-re.

Az mp3fs egy olyan read only virtualis fajlrendszer, aminek egyik felen a flac fajlok vannak, a masik felen pedig mp3-nak mutatott flac fajlok, ha megnyitunk egy ilyen filet akkor lekonvertalja nekunk runtime…

Bovebb info itt.

Java, jpeg, exception

Az egyik publikus képfeltöltő szervlet kapcsán jeleztek egy hibát, hogy valamiféle csodaképeket egyszerűen nem lehet feltölteni. A naplófájlok elemzése után látszott is a hiba:

java.lang.IllegalArgumentException: Numbers of source Raster bands and source color space components do not match
 at java.awt.image.ColorConvertOp.filter(ColorConvertOp.java:460)
 at com.sun.imageio.plugins.jpeg.JPEGImageReader.acceptPixels(JPEGImageReader.java:1114)
 at com.sun.imageio.plugins.jpeg.JPEGImageReader.readImage(Native Method)
 at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:1082)
 at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:897)
 at javax.imageio.ImageIO.read(ImageIO.java:1422)
 at javax.imageio.ImageIO.read(ImageIO.java:1282)

A hiba viszonylag könnyen reprodukálható volt, tehát volt egy jó képem, és egy rossz. A gimp semmi extrát nem mondott a képről, és a rossz kép az ismételt elmentés után is rossz maradt.

Kis keresgélés után rátaláltam az exiftool nevű alkalmazásra:

exiftool -a -G ./JUT430-1.jpg

Látszott is, hogy a kép adatai között mindenféle furcsaság található:

[JFIF] JFIF Version : 1.01
 [JFIF] Resolution Unit : inches
 [JFIF] X Resolution : 300
 [JFIF] Y Resolution : 300
 [ICC_Profile] Profile CMM Type : HDM
 [ICC_Profile] Profile Version : 2.4.0
 [ICC_Profile] Profile Class : Output Device Profile
 [ICC_Profile] Color Space Data : CMYK
 [ICC_Profile] Profile Connection Space : Lab
 ...
[ICC_Profile] Profile Description : ISO Coated v2 (ECI)
 [ICC_Profile] Char Target : (Binary data 126677 bytes, use -b option to extract)
 [EXIF] Modify Date : 2012:08:21 09:56:35
 [EXIF] Compression : JPEG (old-style)
 [EXIF] Thumbnail Offset : 1829717
 [EXIF] Thumbnail Length : 5947

Ekkor gyanús lett a dolog, az én képeimen nem volt ennyi szemét. Letöröltem az összes exif adatot:

exiftool -all= ./JUT430-1.jpg

A dolog működött, a kép megnyitható java-ban. Innen már azt hittem egyszerű a dolog, már csak meg kellene oldani, hogy az exif adatokat a java is le tudja kapni feldolgozás előtt.

Erre találtam is egy ígéretes projektet az Apache common’s Sanselan-t. Az mondjuk furcsa volt, hogy még incubator-os, béta, és 3 éve senki nem nyúlt hozzá, de abból indultam ki, hogy biztosan azért mert annyira jó… 🙂

Természetesen a dolog nem működött. A forráskód tanulmányozása során feltűnt, hogy az általam használt kódból mintha hiányzott volna az érdemi rész…

</pre>
public void removeExifMetadata(ByteSource byteSource, OutputStream os)
 throws ImageReadException, IOException, ImageWriteException
 {
 JFIFPieces jfifPieces = analyzeJFIF(byteSource);
 List pieces = jfifPieces.pieces;

//Debug.debug("pieces", pieces);

//pieces.removeAll(jfifPieces.exifPieces);

//Debug.debug("pieces", pieces);

writeSegmentsReplacingExif(os, pieces, null);
 }
<pre>

Gondoltam ez így nem a legjobb, ezért visszacommenteztem (nyílt forráskód rulz) a removeAll-t. Sajnos ez még önmagában nem jelentett megoldást, ugyanis nem minden addicionális adat EXIF adat, és pont azok az adatok maradtak a képen, amik a problémát okozták.

Minden JFIFPieceSegment eltávolítása nem minősült kimondottan jó taktikának, de egy kis wikipedia-s utánaolvasás után megvolt, hogy mik az egyéb adatok marker bit-jei, amikre nekem semmi szükségem, innen már csak pár sor választott el a sikertől…


public void removeExifAndAllMetadata(ByteSource byteSource, OutputStream os)
 throws ImageReadException, IOException, ImageWriteException
 {
 JFIFPieces jfifPieces = analyzeJFIF(byteSource);
 List pieces = jfifPieces.pieces;

//Debug.debug("pieces", pieces);

 Iterator it = pieces.iterator();

 while (it.hasNext()) {
   Object object = (Object) it.next();
   if (object instanceof JFIFPieceSegment ) {
     JFIFPieceSegment iffdat=(JFIFPieceSegment)object;
     if (iffdat.marker>= 0xFFE0 && iffdat.marker<=0xFFEF) {
        it.remove();
     }
   }
 }

 pieces.removeAll(jfifPieces.exifPieces);

//Debug.debug("pieces", pieces);

writeSegmentsReplacingExif(os, pieces, null);
 }

A végeredmény valami ilyesmi lett:

public static void main(String[] args) {
 try {
String fileName="c:/JUT430-1.jpg";
File f=new File(fileName);
ExifRewriterAdv eRewriter=new ExifRewriterAdv();
FileInputStream fis=new FileInputStream(f);
ByteSourceInputStream bis=new ByteSourceInputStream(fis, null);
ByteArrayOutputStream bout=new ByteArrayOutputStream ();
eRewriter.removeExifAndAllMetadata(bis, bout);
ByteArrayInputStream iobis=new ByteArrayInputStream(bout.toByteArray());
ImageIO.read(iobis);
 } catch (Exception e) {
e.printStackTrace();
 }
 }