Skip to content

Instantly share code, notes, and snippets.

View jbaruch's full-sized avatar
🎩
DevRel all the way

Baruch Sadogursky jbaruch

🎩
DevRel all the way
View GitHub Profile
---
version: 1
GeneralConfiguration:
licenseKey : "NOTAREALLICENSE"
baseUrl : "https://mycomp.arti.co"
proxies :
- key : "proxy1"
@jbaruch
jbaruch / volumes.md
Last active October 13, 2015 14:33
Running Artifafctory with persistent volume
  • mkdir projects/homes
  • docker create -v ~/projects/homes/artifactory-home/data:/var/opt/jfrog/artifactory/data -v ~/projects/homes/artifactory-home/logs:/var/opt/jfrog/artifactory/logs -v ~/projects/homes/artifactory-home/backup:/var/opt/jfrog/artifactory/backup -v ~/projects/homes/artifactory-home/etc:/var/opt/jfrog/artifactory/etc --name artifactory_home jfrog-docker-registry.bintray.io/jfrog/artifactory-pro:4.1.3
  • docker run -d -p 8081:8081 --volumes-from artifactory_home --name artifactory jfrog-docker-registry.bintray.io/jfrog/artifactory-pro:4.1.3
  • Artifactory will not start. It starts with user artifactory, which can't create directories and files in host's user directory - see RTFACT-8310. But it will cerate a default file from which the username is taken.
  • vi ~/projects/homes/artifactory-home/etc/default //change the artifactory user to root
  • docker start artifactory
@jbaruch
jbaruch / bintrayPublish.yml
Created December 29, 2014 09:52
Bintray publish config
---
repo: "maven" #name of the Bintray repository to deploy to
userOrg: "optionalOr" #optinal: organization that the repository belongs to. If not set, the subject will be the user executing the call
name: "mypkg" #name of the package to deploy to. Will be created if not exists
desc: "what a fantastic package indeed!"
websiteUrl: "https://github.com/bintray/gradle-bintray-plugin"
issueTrackerUrl: "https://github.com/bintray/gradle-bintray-plugin/issues"
vcsUrl: "https://github.com/bintray/gradle-bintray-plugin.git"
licenses: # list of licenses of the package from this list: https://bintray.com/docs/api/#_footnoteref_1
- "Apache-2.0"
This file has been truncated, but you can view the full file.
Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
java.lang.ClassNotFoundException: org.apache.juli.ClassLoaderLogManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.util.logging.LogManager$1.run(LogManager.java:191)
at java.security.AccessController.doPrivileged(Native Method)
package conference;
import java.util.Date;
/**
* Created by Jeka on 07/10/2014.
*/
public class Talk {
package conference;
import java.util.HashSet;
import java.util.Set;
/**
* Created by Jeka on 07/10/2014.
*/
public class Speaker {

Keybase proof

I hereby claim:

  • I am jbaruch on github.
  • I am jbaruch (https://keybase.io/jbaruch) on keybase.
  • I have a public key whose fingerprint is 7F53 474E 184A 142F DF94 FCDC 6AC4 1131 A0DB 78AC

To claim this, I am signing this object:

Looking at slide 6: Reza, come on. How can you claim your Spring code example is relevant?! You can find this XML hell only in legacy projects, similar to those which use J2EE EJB 2.1.

That's OK comparing the code at slide 6 to EJB 2.1 deployment descriptor. Or to compare code at slide 8 to Spring Boot/Annotations/Groovy config. But what you do, comparing 6 to 8 is just cheating. It will probably work for you when preaching to people who never used or seen Spring in their life, but doesn't winning by FUD make your victory a bit bitter?

I mean, we (JFrog) are in a same kind of a bitter competition with Sonatype.

class ThridPartyCoolApi {
enum Number {
one(1), two(2), three(3)
int value
Number(int value) {
this.value = value
}
@jbaruch
jbaruch / j1mow
Created April 3, 2012 19:24
От сборки к релизу - как перестать беспокоиться и начать доверять процессу
Частое развертывание в разнообразные производственные среды увеличивает нагрузку на DevOps. Гарантировать, что приложение развернуто правильно, становится все
сложнее.
В ходе этого доклада будут рассмотрены некоторые распространенные ошибки в традиционной непрерывной интеграции, увеличивающие риск и объем ручной работы.
Эти ошибки приводят к проявлению человеческого фактора, заставляя DevOps нервничать перед нажатием кнопки «Deploy».
Далее мы продемонстрируем способы автоматизации, позволяющие преодолеть эти проблемы с помощью уже используемых популярных инструментов:
системы сборки (Maven, или Gradle), сервера непрерывной интеграции (Jenkins, Bamboo или TeamCity) и с помощью бинарного репозитория.
Вне зависимости от того, создаете ли вы программное обеспечение для облачных платформ или для собственной инфраструктуры, мы продемонстрируем,