블로그 이미지
올해목표 // 10월 어학연수 떠나자~ 자수씨

카테고리

전체글 (1457)
Brand New! (28)
주절주절 (213)
MOT (11)
해외쇼핑 (49)
쇼핑노트 (150)
취미생활 (94)
iPhone (4)
Eclipse (121)
Google (83)
Spring (31)
JAVA (176)
JavaScript (59)
WEB (49)
Database (20)
OS (26)
Tools (8)
Tips (26)
IT정보 (1)
Book (21)
Programming (37)
외부행사 (43)
주변인들 (17)
여행노트 (60)
학교생활 (30)
회사생활 (52)
사회생활 (5)
외국어공부 (12)
잡동사니 (30)
Total
Today
Yesterday
 
05-10 04:13
 

달력

« » 2024.5
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
 

최근에 올라온 글

최근에 달린 댓글


구글 드라이브의 스프레드 시트에 행단위로 조건부 서식을 지정하기 위해서는 다음과 같은 번거로운 작업이 필요합니다.



일단 소스는 아래와 같은 스프레드 시트가 존재하며, 진행상황에 따라서 행단위로 서식을 적용할 예정입니다.



서식 > 조건부 서식... 을 선택한 후




아래와 같은 조건부 서식을 입력합니다.

  > 맞춤 수식을 선택한 후

  > 완료의 경우에는

   >> =EXACT(LOOKUP("완료", $A2:$J2), "완료") 

  > 배경이나 텍스트의 색상을 선택하고

  > 범위를 지정합니다. 범위는 서식을 적용할 영역을 의미합니다.


제가 입력한 수식은 아래와 같습니다.

=EXACT(LOOKUP("완료", $A2:$J2), "완료")

=EXACT(LOOKUP("이슈", $A2:$J2), "이슈")

=EXACT(LOOKUP("미진행", $A2:$J2), "미진행")

=EXACT(LOOKUP("진행", $A2:$J2), "진행")


만약에 범위가 A ~ AA 열 까지이고, 2 ~ 30 행까지라면, 범위는 "A2:AA30" 이고, 위에서 LOOKUP에 사용되는 범위는 "$A2:$AA2" 입니다.




하나씩 해보시고 정상적으로 나오면 다른 서식을 적용하시면 됩니다~




Posted by 자수씨
, |

소니 액션캠을 쓰다보니 외부 온도 차이 때문에 방수 케이스에 서리가 끼곤 합니다.




그렇다고 정품 시트를 사기에는 돈이 좀 아깝고...

[에누리 링크]



집에 있는 화장솜을 넣어보았습니다. 방수케이스에도 여유공간이 있어서 잘 들어가는군요.






실제로 사용해본 결과!!! 정품만큼은 아니여도 효과는 있네요 ㅋㅋㅋ


Posted by 자수씨
, |
괜찮은 글들 스크랩!!! 

일단 2011년 자료만,,,


이 좋은 글들을 왜 진작에 보질 못하였을까/// 왜 이런 생각을 하지 못하였을까/// 이러니깐 우물안에서 벗어나질 못하는 것이다///


아참 나 이 시기에 대학원에 있었지? ㅋㅋㅋ

Posted by 자수씨
, |

요즘 포장에 관심이 생겨서 보티브 홀더를 담을 수 있는 케이스를 구매하기 위해 사이즈를 측정해 보았다.







가로: 5cm, 세로: 5cm, 높이: 7cm 로 측정되었다. (가로/세로는 하단부 지름을 측정... 상단부 지름은... 추후 업데이트)

상단부 지름은 가로 5.7cm, 세로 5.7cm 이다.


그냥 보티브 사이즈는 상단 지름을 기준으로 가로 5cm, 세로 5cm, 높이 5cm 정도이다.


이 사이즈면 http://www.makepack.co.kr/product/detail.html?product_no=1657&cate_no=155&display_group= 의 초미니 싸이즈가 딱 맞다.


이미지 출처: 메이크팩(http://www.makepack.co.kr/)



가격은 50장에 11,000원 일단 50장 주문을 해 봐야겠다.





Posted by 자수씨
, |


Alfresco 는 CMIS 이다. CMIS 를 대상으로 컨텐츠 모델링을 할 때는 일반 RDB 모델링 하듯이 하면 완전 피본다는 것을 뼈저리게 느끼고 있다.


일단, JOIN 이 지원되지 않는다는 것은 타격이 크다. SOLR 은 4.0 이상 부터 JOIN 을 지원하는데, Alfresco 4.0 에서는 SOLR 1.4 버전을 사용한다. CMIS Query 에서 JOIN 을 제공해주는 예제를 확인하여 테스트를 해보았으나 커스텀 타입의 데이터 모델은 "Advanced join is not supported" 익셉션만 뱉을 뿐이다...


검색을 하다가 찾은 내용인데, 안습...


The bottom-line is that Alfresco isn't relational. You can set up associations and through the API you can ask a give node for its associations, but you cannot run queries across associations like you can when you do joins in a relational database.


Maybe you should add a location property to your content node and update its value with a behavior any time an association is created, updated, or deleted on that node. Then you'd be able to run a query by AND-ing the location with other criteria on the node.


Obviously, if you have many such properties that you need to keep in sync your behavior could start to affect performance negatively, but if you have only a handful you should be okay.


출처: http://stackoverflow.com/questions/11193275/alfresco-solr-custom-search


대충 내용은 Alfresco 는 relational 하지 않다. RDB 처럼 join 을 할 수 없다. 노드의 생성, 갱신, 삭제 시에 관련 프로퍼티를 업데이트 해주어야 한다. 이 것은 성능에 부정적인 영향을 끼친다. 얼마 안되는 정도라면 괜찮다.


결국, behaviour 를 이용하여 업데이트 하는 방법은 절대 절대 피해야 하는데 방법이 보이질 않는다...


SOLR 을 4.0 으로 올릴 수는 없을까?



Posted by 자수씨
, |

[ALFRESCO_HOME]/webapps/alfresco/WEB-INF/classes/log4j.properties

###### File appender definition #######

log4j.appender.File=org.apache.log4j.DailyRollingFileAppender

log4j.appender.File.File=alfresco.log

log4j.appender.File.Append=true

log4j.appender.File.DatePattern='.'yyyy-MM-dd

log4j.appender.File.layout=org.apache.log4j.PatternLayout

log4j.appender.File.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c] %m%n



[ALFRESCO_HOME]/webapps/awe/WEB-INF/classes/log4j.properties

###### File appender definition #######

log4j.appender.File=org.apache.log4j.DailyRollingFileAppender

log4j.appender.File.File=awe.log

log4j.appender.File.Append=true

log4j.appender.File.DatePattern='.'yyyy-MM-dd

log4j.appender.File.layout=org.apache.log4j.PatternLayout

log4j.appender.File.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c] %m%n



[ALFRESCO_HOME]/webapps/solr/WEB-INF/classes/log4j.properties

###### File appender definition #######

log4j.appender.File=org.apache.log4j.DailyRollingFileAppender
log4j.appender.File.File=solr.log
log4j.appender.File.Append=true
log4j.appender.File.DatePattern='.'yyyy-MM-dd
log4j.appender.File.layout=org.apache.log4j.PatternLayout
log4j.appender.File.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c] %m%n



[ALFRESCO_HOME]/webapps/wcmqs/WEB-INF/classes/log4j.xml

<appender name="file" class="org.apache.log4j.DailyRollingFileAppender">

<param name="File" value="webquickstart.log" />

<param name="Append" value="true" />

<param name="Encoding" value="UTF-8" />

<param name="DatePattern" value="'.'yyyy-MM-dd" />

<layout class="org.apache.log4j.PatternLayout">

<param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c] %m%n" />

</layout>

</appender>




Posted by 자수씨
, |


UI 를 구성하는 Web Scripts 는 request 나 response 객체에 접근이 어렵기 때문에 Web Scripts 내에서 redirect 를 하려면 약간의 꼼수를 이용해야 한다.


Response Status 를 이용하는 꼼수인데, Response Status 로 핸들링하는 예제는 아래 더보기를 통해 확인할 수 있다. 




이번 포스팅에서 사용하는 방식은 "Package level template named <format>.status.ftl" 으로 사용하는 Web Scripts 와 같은 패키지(디렉토리)에 위치시키고 js 파일에서 status 를 제어하여 redirect 를 시킬 것이다.



/alfresco/web-extension/site-webscripts/test/package/test.content.get.js



위에서 redirectCondition 이 true 이면, status.code 에 899 값을 설정하고, status.location 에는 redirect 할 url 을, status.redirect 는 true 로 설정을 하고 실행하는 함수 자체를 return 시켜서 아래 코드가 실행되지 않도록 한다.


/alfresco/web-extension/site-webscripts/test/package/html.status.ftl


html.status.ftl 은 "/alfresco/web-extension/site-webscripts/test/package/" 하위에 있는 *.html.ftl 에서 status 값이 설정되면 해당 페이지로 리다이렉트하게 된다.



잘만 이용하면 다양한 기능을 활용할 수 있을 듯 하다.



Posted by 자수씨
, |

파라미터로 long 형 timestamp 를 넘겨주면, 

  1분 이내는 방금

  1시간 이내는 ~분 전

  하루 이내는 ~시간 전

  나머지는 날짜 출력





=ㅁ= //


Posted by 자수씨
, |

참고자료: http://wiki.alfresco.com/wiki/Full-Text_Search_Configuration



각 프로퍼티의 인덱싱 행위는 컨텐츠 모델에서 설정될 수 있다. 기본적으로 원자적으로 인덱싱 된다. 프로퍼티 값은 인덱스 안에 저장되지 않고, 프로퍼티는 인덱싱 될 때, 토큰화 된다.


The following example shows how indexing can be controlled.


Enabled="false"

false 이면, 인덱스에 이 프로퍼티를 위한 엔트리는 없다.


Atomic="true"

true 이면, 프로퍼티는 트랜잭션 내에서 인덱싱되며, false 이면 프로퍼티는 백그라운드에서 인덱싱 된다.

(Indexing of content that requires transformation before being indexed (e.g. PDFs) will only obey Atomic=true if the transformation takes less time than the value specified for lucene.maxAtomicTransformationTime. See #General.)


Stored="true"

true 이면, 프로퍼티 값은 인덱스 내에 저장되고, 루씬 로우 레벨 쿼리 API를 통해 얻을 수 있다.

(This can be useful while debugging systems to see exactly what is being indexed, but do not set this to true on production systems.)


Tokenised="true"

"true" 이면, 프로퍼티의 문자열 값은 인덱싱 전에 토큰화 된다.

"false" 이면, 단일 문자열로 인덱싱 된다.

"both" 이면, 두 가지 형태로 인덱에 존재하기 된다.



Posted by 자수씨
, |

기본 퍼미션 모델

JAVA/Alfresco / 2014. 1. 27. 18:43

마찬가지로 개인 참고용으로 정리합니다.

참고자료: https://wiki.alfresco.com/wiki/Default_Permissions_Model_Reference#Base_permissions

sys:base

기본 퍼미션

  • _ReadProperties: 노드의 속성 읽기에 대한 접근을 제한. 컨텐츠 접근은 개별적으로 제어됨. 모든 속성은 동일한 접근 제한을 가짐.
  • _ReadChildren: 자식 노드의 읽기에 대한 접근을 제한. 개별 자식 노드에 설정된 권한이 우선 적용됨. 이 권한이 부여되지 않으면 자식노드를 탐색할 수 없음.
  • _WriteProperties: 노드의 모든 속성에 대한 쓰기에 대한 접근을 제한. 컨텐츠 접근은 개별적으로 제어됨. 모든 속성은 동일한 접근 제한을 가짐
  • _ReadContent: 노드에 대한 모든 컨텐츠의 읽기에 대한 접근을 제한
  • _WriteContent: 노드에 대한 모든 컨텐츠의 생성과 갱신에 대한 접근을 제한
  • _ExecuteContent: 컨텐츠 실행에 대한 접근을 제한
  • _DeleteNode: 노드 삭제에 대한 접근을 제한. 현재 노드의 모든 자식 노드를 삭제할 권한을 가지거나 부모로 부터 자식 노드를 삭제할 수 있는지를 체크하지 않음.
  • _DeleteChildren: 자식 노드의 삭제에 대한 접근을 제한
  • _CreateChildren: 새로운 자식 노드 생성에 대한 접근을 제한
  • _LinkChildren: 이미 존재하는 노드에 보조 어소시에이션 생성에 대한 접근을 제한
  • _DeleteAssociations: 노드에 대한 non-child-associations 삭제에 대한 접근을 제한
  • _ReadAssociations: 노드에 대한 non-child-associations 읽기에 대한 접근을 제한
  • _CreateAssociations: 노드에 대한 non-child-associations 생성에 대한 접근을 제한
  • _ReadPermissions: 노드에서 읽기 권한에 대한 접근을 제한
  • _ChangePermissions: 노드에서 쓰기 권한에 대한 접근을 제한

기본 그룹

  • FullControl: 다른 모든 권한을 허용하는 권한 그룹
  • ReadProperties: _ReadProperties 에서 부여됨
  • ReadChildren: _ReadChildren 에서 부여됨
  • WriteProperties: _WriteProperties 에서 부여됨
  • ReadContent: _ReadContent 에서 부여됨
  • WriteContent: _WriteContent 에서 부여됨
  • ExecuteContent: _ExecuteContent 에서 부여됨
  • DeleteNode: _DeleteNode 에서 부여됨
  • DeleteChildren: _DeleteChildren 에서 부여됨
  • CreateChildren: _CreateChildren 에서 부여됨
  • LinkChildren: _LinkChildren 에서 부여됨
  • DeleteAssociations: _DeleteAssociations 에서 부여됨
  • ReadAssociations: _ReadAssociations 에서 부여됨
  • CreateAssociations: _CreateAssociations 에서 부여됨
  • ReadPermissions: _ReadPermissions 에서 부여됨
  • ChangePermissions: _ChangePermissions 에서 부여됨

복합 그룹

  • Read: ReadProperties, ReadChildren, ReadContent 의 조합
  • Write (Update in CRUD): WriteProperties 와 WriteContent 의 조합
  • Delete: DeleteNode 와 DeleteChildren 의 조합
  • AddChildren (Create in CRUD): CreateChildren 과 LinkChildren 의 조합
  • Execute: 그냥 ExecuteContent

cm:object

복합 그룹

  • Administrator: 모든 권한을 갖음. 이전 버전과의 호환성을 위해...
  • Coordinator: 모든 권한과 정의된 권한 그룹을 가져옴
  • Collaborator: Editor 와 Contributor 권한의 조합
  • Contributor: Consumer 권한 그룹에 AddChildren과 CheckOut 이 추가됨. 기본적으로 자신이 만든 것을 소유하고 ROLE_OWNER 권한이 있어야 함
  • Editor: Consumer 권한 그룹에 Write 와 CheckOut 이 추가됨
  • Consumer: Read 를 포함
  • RecordAdministrator: ReadProperties, ReadChildren, WriteProperties, ReadContent, DeleteChildren, CreateChildren, LinkChildren, DeleteAssociations, CreateAssociations 를 포함

cm:folder

복합 그룹

  • cm:object 와 유사. Administrator 권한 그룹만 없음

cm:ownable

기본 권한

  • _SetOwner: 노드에서 권한 설정을 제한. 이 권한은 _WriteProperties 도 부여해야 함.

기본 그룹

  • SetOwner: _SetOwner 에서 부여됨

복합 그룹

  • TakeOwnership: SetOwner 를 포함

cm:lockable

기본 권한

  • _Lock: 노드 잠금에 대한 접근을 제한
  • _Unlock: 노드 잠금 해제에 대한 접근을 제한

기본 그룹

  • Lock: _Lock 에서 부여됨
  • Unlock: _Unlock 에서 부여됨

복합 그룹

  • CheckOut: Lock 을 포함
  • CheckIn: Unlock 을 포함
  • CancelCheckOut: Unlock 을 포함


전역 권한

  • "FullControl" 은 "ROLE_ADMINISTRATOR" 에 부여됨: 관리자는 어떤 것도 할 수 있음
  • "FullControl" 은 "ROLE_OWNER" 에 부여됨: 소유자는 모든 권한이 허용됨
  • "Unlock" 은 "ROLE_LOCK_OWNER" 에 부여됨: 잠금의 소유자는 언제든지 잠금을 풀 수 있음
  • "CheckIn" 은 "ROLE_LOCK_OWNER" 에 부여됨: 잠금의 소유자는 문서를 체크인 할 수 있음
  • "CancelCheckOut" 은 "ROLE_LOCK_OWNER" 에 부여됨: 잠금의 소유자는 문서의 체크아웃을 취소할 수 있음



Posted by 자수씨
, |

글 보관함

최근에 받은 트랙백