Eclipse – Required projects on the build path

Nem tudom, hogy miért velem történik mindig az, hogy egy 5 perces dolog 1 óráig tud tartani. Valamiért az eclipse úgy döntött, hogy a Required projects on the build path opció beadja az unalmast, és nem működik. Végigtúrtam a fél internetet, kevés sikerrel… Amikor már kezdtem ráunni a dologra, csináltam egy új workspace-t, megnéztem, mit ír bele az eclipse a .classpath fájlba, és beleírtam kézzel:

<classpathentry combineaccessrules="false" kind="src" path="/cloudsync_common"/>

Close, open project és láss csodát, működik… pff…

A ma este tanúsága:
42067_019_Alternate2

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.

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();
 }
 }

Diablo 3

Nem hittem volna, hogy valaha ezt fogom mondani (kiálltam érte, védtem), de ha valaki azt tervezi, hogy diablo 3-at vesz, írja inkább be a böngészőjébe:

http://error37.com

Olcsóbb, az élmény pedig ugyanaz.

A blizzard meg egy szánalom. Komolyan.

SyncToCloud.net

Nagy nehezen elindult végre a synctocloud.net.
Mint minden jó release esetén az utolsó pillanatokban még hibákat javítottam (egész pontosabban próbáltam megcsinálni azokat a dolgokat, amikről már azt hittem, hogy rég megcsináltam őket).
És mint minden jó program esetében itt sem az a kérdés, hogy van e benne hiba, inkább csak az, hogy mennyi 🙂

Eclipse Class cache

Az új eclipse verzió óta elég gyakran megesik velem, hogy egy két projektben egyszerűen nem működik az auto-import, open by type, és ehhez hasonló nyalánkságok.

Erre a megoldás egyszerű, törölni kell a workspace/.metadata/.plugins/org.eclipse.jdt.core könyvtárból a *.index and savedIndexNames.txt fájlokat…

Excel open in new window

Az egész világ Jobs haláláról beszél (ma a zite-ba nem találtam olyan topicot, amiben a 10 cikkből legalább 7 ne erről szólt volna). Én pedig még mindig a miocrosoft ördögi találmányaival harcolok. Nem tudom ki találta ki, hogy az excel nem tud azonos nevű fájlt megnyitni (hiába más a fájl elérése), és nem lehet két excel ablakot KÜLÖN használni… De az ilyen embert legalább egy kirúgással kellene jutalmazni.

Persze mint mindent, ezt is át lehet állítani, igazán minőségi eredeti windowsos ablakokban (amik még a windows 95-ből maradtak fenn), amit nem lehet nagyítani, így egy bélyeg méretű helyen kell átpörgetni a több ezer ismert kiterjesztést, egy olyan listában ahol se csoportosítva nincs semmi, és még keresni se lehet…

És aki ezt mind végigcsinálja, egy idő után azt tapasztalja, hogy bizonyos alkalmazások (telepítése, vagy működése, vagy csak a véletlen folyamán), az egész eltűnik, és csinálhatja meg újra.

Én is ezt csináltam minden windowson, néha működött, néha nem, egészen addig amíg meg nem untam és ma nem kerestem picit tovább. Gondoltam csak másnak is eszébe jutott ami nekem.

És nem meglepő módon igen: http://www.bitterminion.com/excel-instance-launcher/

Jól indult a napom, adtam is nekik 10 dollárt, mert megérdemlik.

Javadoc generálás statikus adatokkal

A javadoc fontos, főleg ha publikus szolgáltatásokat készítünk. Néha viszont szükség van olyan algoritmus alapján előállított adatokra, amiket nem esik túl jól kézzel beírni…

Ilyenkor nyújthat nagy segítséget egy két shell script, amikkel az ilyen módosítások elég hatékonyan elvégezhetőek.
A scriptet nem hiszem, hogy bárki is tudja majd használni ebben a formában, de kiindulásnak (és nekem memó-nak) még jól jöhet…

A lenti dolog mit is csinál:
– kigyűjti az összes /services/ könyvtár alatti package-info.java-t
– kikalkulálja, hogy mi lesz a kiajánlott szolgáltatás neve (pl TestWebSzolgService.java – TestWebSzolg)
– csinál belőle egy javadoc szöveget, amit beszúr az összes package-info első sorába

Tadamm… Pár óra szolgai gépeléstől megint megmentett a bash.

#!/bin/sh
find . -name "package-info.java" | grep "/services/" | while read line;
do
#teljes eleres
PACKAGE_INFO_PATH=$line
#csak a konyvtar ahol a packageinfo van
CURR_DIR=${PACKAGE_INFO_PATH%/*}
#a valamiService.java fajl teljes elerese (de mar Service.java nelkul)
CURR_SERVICE_PATH=`find $CURR_DIR -name "*?Service.java" | sed 's/Service.java//'`
#csak a szolgaltatas neve
CURR_SERVICE_NAME=${CURR_SERVICE_PATH##*/}

echo $PACKAGE_INFO_PATH
echo $CURR_DIR
echo $CURR_SERVICE_NAME

FIRST_LINE="/** WSDL: https://webservice.aaa.hu/da/hs/services/${CURR_SERVICE_NAME}*/"

sed -i 1i"$FIRST_LINE" $PACKAGE_INFO_PATH
done