отсюда
Sunday, October 23, 2011
Wednesday, October 19, 2011
Thursday, October 13, 2011
джеф клэйз
BUILDING SMALL THINGS
Jef Claes
Due to the nature of things we build in our day to day job, writing software can wear out even the most fit of us.
Most software jobs make you constantly deal with complexity. The amount of things which can lead to a complex software project are immense. A poor first design, and failure to redesign. External dependencies, which seem to behave different every time around. Or just the complexity of the problems itself.
You are almost always working in a team, which can be exhausting as well. If the team doesn't share your passion and you have a hard time getting your ideas across, you will get frustrated, real soon. Add some coroporate politics to the mix and you'll be on your way to Paranoia.
It feels like I'm turning this into a rant, but I'll stop right here, you get where I'm going at. Building software in the real world can be hard. Very hard.
I like to think building something small on your own once in a while can be extremely liberating. It can help you keep your sanity and not lose your passion towards software. You pick what to build. Something small. Something new. Something built with your favorite tools, on your favorite platform. Something that can be shipped. Something which takes only you and your machine.
Having problems finding something meaningful to make? Look around you, the most trivial problem can lead to a satisfying little sideproject. Look for things that bother you, and try making them bother you less. Listen to others, maybe you can help solve their problems. Who cares if it already exists in one way or the other? Look for something that looks fun. And just build it.
Jef Claes
Due to the nature of things we build in our day to day job, writing software can wear out even the most fit of us.
Most software jobs make you constantly deal with complexity. The amount of things which can lead to a complex software project are immense. A poor first design, and failure to redesign. External dependencies, which seem to behave different every time around. Or just the complexity of the problems itself.
You are almost always working in a team, which can be exhausting as well. If the team doesn't share your passion and you have a hard time getting your ideas across, you will get frustrated, real soon. Add some coroporate politics to the mix and you'll be on your way to Paranoia.
It feels like I'm turning this into a rant, but I'll stop right here, you get where I'm going at. Building software in the real world can be hard. Very hard.
I like to think building something small on your own once in a while can be extremely liberating. It can help you keep your sanity and not lose your passion towards software. You pick what to build. Something small. Something new. Something built with your favorite tools, on your favorite platform. Something that can be shipped. Something which takes only you and your machine.
Having problems finding something meaningful to make? Look around you, the most trivial problem can lead to a satisfying little sideproject. Look for things that bother you, and try making them bother you less. Listen to others, maybe you can help solve their problems. Who cares if it already exists in one way or the other? Look for something that looks fun. And just build it.
ускоряем пинг
надоело окрывать кмд, писать пинг и вообще...
берем этот код в текстовый файл и меняем на .vbs
strComputers = "192.168.98.5,LA1DVCONSVR001,jenkins.d3nw.net" 'use comma: "192.168.98.5,192.168.98.6"
arrComputers = SPLIT(strComputers, ",")
for each strComputer in arrComputers
set objPing = GetObject("winmgmts:{impersonationLevel=impersonate}")._
ExecQuery("select * from Win32_PingStatus where address = '" & _
strComputer & "'")
for each objPingStatus in objPing
if ISNULL(objPingStatus.StatusCode) or objPingStatus.StatusCode<>0 then
if strFailedPings <> "" then strFailedPings = strFailedPings & vbcrlf
strFailedPings = strFailedPings & strComputer
end if
next
next
if strFailedPings = "" then
strOK = "Ping status of specified computers is OK:" & vbcrlf
for each strComputer in arrComputers
strOK = strOK & strComputer & vbcrlf
next
wscript.echo strOK
else
wscript.echo "Ping failed for the following computers:" & _
vbcrlf & vbcrlf & strFailedPings
end if
берем этот код в текстовый файл и меняем на .vbs
strComputers = "192.168.98.5,LA1DVCONSVR001,jenkins.d3nw.net" 'use comma: "192.168.98.5,192.168.98.6"
arrComputers = SPLIT(strComputers, ",")
for each strComputer in arrComputers
set objPing = GetObject("winmgmts:{impersonationLevel=impersonate}")._
ExecQuery("select * from Win32_PingStatus where address = '" & _
strComputer & "'")
for each objPingStatus in objPing
if ISNULL(objPingStatus.StatusCode) or objPingStatus.StatusCode<>0 then
if strFailedPings <> "" then strFailedPings = strFailedPings & vbcrlf
strFailedPings = strFailedPings & strComputer
end if
next
next
if strFailedPings = "" then
strOK = "Ping status of specified computers is OK:" & vbcrlf
for each strComputer in arrComputers
strOK = strOK & strComputer & vbcrlf
next
wscript.echo strOK
else
wscript.echo "Ping failed for the following computers:" & _
vbcrlf & vbcrlf & strFailedPings
end if
Wednesday, October 12, 2011
вдруг пригодится: sql для крутых
добавив одну строчку в самом конце sql запроса, вы можете получить результат в виде xml, а не в виде обычной таблицы:
For XML Auto, Type, Elements, Root('Whatever_you_want')
вдруг пригодится...
ну, а под катом - уж для совсем крутых...
For XML Auto, Type, Elements, Root('Whatever_you_want')
вдруг пригодится...
ну, а под катом - уж для совсем крутых...
Tuesday, October 11, 2011
знаменитые уроженцы верчелли
молодцы!
Saturday, October 8, 2011
Thursday, October 6, 2011
две иконки
новая иконка: выключить комп:
%windir%\system32\shutdown.exe -s -t 00
перезагрузка:
%windir%\system32\shutdown.exe -r -t 00
контрольная панель для настоящих пацанов
да хоть на рабочем столе:
новая папка, наименовать вот так:
XXX.{ED7BA470-8E54-465E-825C-99712043E01C}
все до точки - на усмотрение.
красота.
новая папка, наименовать вот так:
XXX.{ED7BA470-8E54-465E-825C-99712043E01C}
все до точки - на усмотрение.
красота.
Wednesday, October 5, 2011
мысли от умных
http://eli.thegreenplace.net/2011/10/04/what-tdd-means-to-me/
What I do before writing code is thinking about the testability of my design. Thinking hard.
Design usually means breaking the solution into components (or modules, or whatever you want to call them), figuring out the responsibility of each component and the interactions between them. There are many aspects to consider when judging a certain design, and I add testability as an important first-class criterion. A design that doesn’t lend itself to being tested, is in my view a bad design, so I start thinking about alternatives.
How does a design lend itself to being tested? By being composed of components that can be tested in isolation.
Isolation is extremely important for debugging problems when they unavoidably arise. It is not easy to achieve – good isolation (a.k.a. encapsulation) of components is a kind of holy grail – you never really find the best division into components, you only approximate it.
I think that testability serves as a good guide – components that are easy to test in separation usually make up a pretty good design. This is because testability and isolation usually go hand in hand. The more coupled a design is, the harder it makes testing its components in isolation. As a corollary – when components are easy to test in isolation, the design is well decoupled.
What I do before writing code is thinking about the testability of my design. Thinking hard.
Design usually means breaking the solution into components (or modules, or whatever you want to call them), figuring out the responsibility of each component and the interactions between them. There are many aspects to consider when judging a certain design, and I add testability as an important first-class criterion. A design that doesn’t lend itself to being tested, is in my view a bad design, so I start thinking about alternatives.
How does a design lend itself to being tested? By being composed of components that can be tested in isolation.
Isolation is extremely important for debugging problems when they unavoidably arise. It is not easy to achieve – good isolation (a.k.a. encapsulation) of components is a kind of holy grail – you never really find the best division into components, you only approximate it.
I think that testability serves as a good guide – components that are easy to test in separation usually make up a pretty good design. This is because testability and isolation usually go hand in hand. The more coupled a design is, the harder it makes testing its components in isolation. As a corollary – when components are easy to test in isolation, the design is well decoupled.
Monday, October 3, 2011
Subscribe to:
Posts (Atom)