Slashdot Mirror

Hipchat supports all of those capabilities and you can serve hundreds of users from a single server instance that uses less RAM than the client side of Slack.

As of February 15, 2019, the client side of HipChat will use exactly the same amount of RAM as the client side of Slack because of Atlassian's deal with Slack to discontinue HipChat, including licenses for on-premises instances, and migrate all HipChat users to Slack. The server side of HipChat will no longer be available to the public at all, as Slack will host all instances on servers operated by Slack. On-premises users who cannot migrate to Slack will have to export their data and import it to some unspecified competing on-premises chat platform. (Source: "Slack Migration Frequently Asked Questions")

What's that got to do with anything? It means something better (from a resource consumption standpoint) existed and Slack is extinguishing it. But your claim was that no one had ever written anything like slack before and that is utter nonsense. Are you somehow financially tied to Slack? Because you obviously can't accept that the Slack client was horribly implemented.

Hipchat supports all of those capabilities and you can serve hundreds of users from a single server instance that uses less RAM than the client side of Slack.

As of February 15, 2019, the client side of HipChat will use exactly the same amount of RAM as the client side of Slack because of Atlassian's deal with Slack to discontinue HipChat, including licenses for on-premises instances, and migrate all HipChat users to Slack. The server side of HipChat will no longer be available to the public at all, as Slack will host all instances on servers operated by Slack. On-premises users who cannot migrate to Slack will have to export their data and import it to some unspecified competing on-premises chat platform. (Source: "Slack Migration Frequently Asked Questions")

That is actually my favorite April Fools prank ever, with Angry Nerds a close second.

Atlassian puts their own bug database online. When you find a problem with Atlassian software you can search for it there. You will likely find that other people have found this problem before you, and opened tickets on it, which Atlassian has since closed, explaining either - yes, it is broken, but fixing it would be hard, so we're not going to OR - no, that's the way it is supposed to work, and we're not going to change it

Agree. There are so many feature requests that would make the tool more useful that they flat out reject because... I guess they don't feel like doing work?

I don't know what Atlassian will do with Trello, but their existing products are horrid.
We use JIRA (a bug tracker) and Confluence (a wiki). These suffer from
- poor use of screen space
- useless search
- crude and inconsistent text editing
- verbose, non-standard, and broken markdown

Atlassian products are built for shelf-appeal: they are designed to look good in sales demos, and to appeal the people who sign POs and checks: CEOs, VPs, and directors. But they don't actually work for the people who have to use them: programmers and first-line managers.

Atlassian puts their own bug database online. When you find a problem with Atlassian software you can search for it there. You will likely find that other people have found this problem before you, and opened tickets on it, which Atlassian has since closed, explaining either
- yes, it is broken, but fixing it would be hard, so we're not going to
OR
- no, that's the way it is supposed to work, and we're not going to change it

Pretty much, but there's a bit more to it in most Git workflows.

-jcr

Atlassian SourceTree isn't the greatest thing on earth, but it is parsecs better than the Xcode crap.

It also bundles a newer version of Git than the Mac (not 2.8, yet, but currently 2.7.4).

I work on a Mac in half a dozen languages and environments, so SourceTree gives me what I need to manage my repos.

I've been out in industry for exactly a decade. I know who they are laying off. I would bet heavily that these are the guys that like doing things the way they have always done things and are content on not improving it. They're the drafters that refused to learn "that CAD thing". You see it all over Slashdot. You guys sure like things the way you used to do them. "Why kids these days don't need to learn Assembly".

I spent a recent layoff learning Python 3.4. It's near impossible to get people off of 2.7 at work or Matlab. Why? Because that's what they learned during undegrad and grad school and that's where everything is written. And they do have a small point, I'm don't have time to go back and re-write 50 years of working software. Once we as a society figured out Linear Algebra in Fortran we stopped messing with it. Numpy, Matlab, et al are just pretty BLAS wrappers.

However at impedes a lot of progress. At this point I feel like I'm in Office Space half the time:

1st Bob: What you do at Initech is you take the specifications from the software engineer and bring them down to the hardware engineers?
Tom: Yes, yes that's right.
2nd Bob: Well then I just have to ask why can't the software engineers use the hardware engineer's API?
Tom: Well, I'll tell you why... because... software engineers are not good at dealing with APIs...
1st Bob: So you physically take the flash files from the software engineer?
Tom: Well... No. The project lead does that... or they're e-mailed....

If you're doing things the same way you did them even a year ago, then some lazier person that does your job is currently writing a script to do it that way. So in 50 years we can all look back and laugh at "Those idiots used to do it by hand". If you write a script to save you 1 minute a day, that's 4 hours a business year. If you write a script to save you and all of your co-workers 1 minute a day. That's an additional 4 hours per head per year. Start adding that up over a decade or two.

It's entertaining to watch you guys not wanting to use new tools, I just started writing new tools to use the old tools I wrote. I could reduce my manager's headcount by 3-4 and keep the same work level output with an improvement in quality. Software engineers have already done that, it's what continuous integration is for. Then they got tired of dealing with merges, so they wrote tools to automatically do merges if everything tests out.

CGP Grey's "Humans Need Not Apply" is a good video on the current state of automation. While I don't share quite his outlook his statements about what is going on right now is dead on. (Humans' will just start building warp drives instead of dicking around with what we do now). If TensorFlow can pick those images out that accurately they sure as heck can read the graphs I used to have to read much, much better. Give me the picture of a tachometer trace and I could tell you what's wrong it your car. I don't need to hear it, see it or know what's going on.

Last night on SharkTank there was a guy that had a mobile app that could take your measurements 20% better than a professional tailor, just by taking some photos and doing some math. If you were hoping to be a tailor and spend time measuring people, I have bad news.

Engineers these days use Simulink. Finding Engineers that can Code is hard. So we taught the en

Haven't heard of that, but I might take a look if you have a link.

This is the article I read: https://developer.atlassian.co... which goes over this usage of optional in the first paragraph.

Without seeing a specific implementation, I have trouble imagining what the advantage could be. Determining whether a key exists, or whether a stored value is null are both simple conditions to write. Why clutter it up with an unnecessary class?

I don't know why you would clutter it up with a class. But for thread safety, you would want to get the answer immediately. If you did something like this it could lead to a false result:
if (hash.contains(key)) {
__// the key is in the hash
__//some other thread removes the key
__value = hash.get(key);
__// this returns null, implying that the value mapped to key was null which it may not have been.
}

you could sycnhronize access to the hash, but you would still need to get answers to both conditions in a single access, and an Optional object is capable of containing both answers in a single object returns by a single function call.

I'll say this about your post of misinformation. No. Just NO.

Either: https://www.atlassian.com/soft...
or: https://code.google.com/p/tort...

But I don't like SCMs that integrate into the Explorer ... to confusing and error prone IMHO.

Just worked an hour on my sisters Windows 8 Explorer/Internet Explorer and stuff: worst software/UI experience ever ... who actually is using such a system? Masochists?

Confluence can be used in vendor cloud or on your own servers:
https://www.atlassian.com/soft...

Try Atlassian Confluence

https://www.atlassian.com/soft...

It is not free (as in beer) but IMO it meets your needs. This is the most user friendly wiki software I know and has roles for knowledge base system and also means to attach files (f.e. videos). You can put in few macros that will automagically embed attached videos in web player.

Read on here:

https://confluence.atlassian.c...

Try Atlassian Confluence

https://www.atlassian.com/soft...

It is not free (as in beer) but IMO it meets your needs. This is the most user friendly wiki software I know and has roles for knowledge base system and also means to attach files (f.e. videos). You can put in few macros that will automagically embed attached videos in web player.

Read on here:

https://confluence.atlassian.c...

I totally agree with what was said above about Confluence: Confluence is a great option for a Wiki. https://www.atlassian.com/soft... And it does support different media types. Whether you actually need a Wiki is a different questions :)

You are doing bug tracking by hand??? We used to that back in the 1990's. I was given a three day task to sort, reorder, prioirtize about 200 open tickets in a single text file. Wrote a script in six hours to do this automatically, and had the report completed in minutes. Today, we would just use bug-tracking software like Jira

https://www.atlassian.com/soft...

Or you could try Atlassian Stash:
https://www.atlassian.com/soft... ...
Or, like me, you see the term "Apache Software" and get drunk on the beer.

Organisations that use single sign on solutions like: https://www.atlassian.com/software/crowd/overview

Using the SSO solution outside the SSO domain is not supported, and if you need to do that, you would generally place a reverse proxy in front of the servers not part of the domain.

Depending on clients compromising their security in order for you to get less work does not instill a lot of confidence in your single sign-on solution and by extension, how safe it is.

examples! real examples that apply to the world

Organisations that use single sign on solutions like: https://www.atlassian.com/software/crowd/overview

not just your private project

My project isn't private, I'm just not mentioning the name because Slashdotters frown upon advertising.

I've hear tons of good things about SourceTree, a freeware Git / Mercurial client originally for Mac but recently released for Windows. I know it's used by lots of non-technical folk for non-coding purposes (think designers managing Photoshop projects), so it might work for your scenario too. I haven't used it myself though so I can't comment from personal experience.

By the way, you could set things so that you'd have a different repository for each project, similar to your set of root folders, instead of a single repository covering everything. That'd keep things neatly separated as users would be able to branch only the specific projects they're working with rather than the whole thing. And since it all comes down to the original files/folders being copied up and down with the addition of a few hidden metadata files/folders, end users wouldn't really notice anything is added under the hood unless they have Explorer set to show hidden files, evidently.

Awesome idea. Reminds me of Atlassian's portal:

http://blogs.atlassian.com/2011/12/developer-lives-saved-with-portal-device/

Well, there is a grain of truth here, 243 and counting: https://jira.atlassian.com/browse/JRA-1330

The terminology in article confused me as well. It's talking about "enterprise single sign-on" which actually means something different from what Crowd actually seems to provide. It's usually used to refer software that does SSO to desktop applications (well known software in that sector are like Oracle ESSO, NetIQ (formerly Novell) SecureLogin, IBM SAM ESSO (formerly IBM TAM ESSO)). Crowd, however, seems to be WebSSO+IDM solution.

Bet any of these guys are worried?

Atlassian boasts that Crowd has more than a thousand corporate users, including the NYSE. Yes, kids, the New York Stock Exchange has internal applications that are affected by this backdoor—along with Sourceforge, Twitter, BMW, Panasonic, Netflix, Zynga...

https://jira.atlassian.com/browse/CWD-3366

No, I don't think you understand how companies work. The most common workflow is update when you arrive and commit when you leave and eventually fix a file and commit it while you are working with something else.

I agree that this workflow is common, but it doesn't really help the developer as much as it could.

I don't want to launch into a huge treatise on common git workflows because there are graphical guides out there that illustrate it much more clearly than I could in a slashdot comment. Check out Atlassian's git workflows page, and in particular, look at the Feature Branch workflow and the Gitflow workflow.

Hopefully that will result in an "Aha!" moment for you, but if not, that's cool. You'll get there eventually. :) Most people who give git a serious try wind up preferring it. It does have a learning curve, though. Which is unfortunate. The curve can be flattened quite a bit with one of the graphical tools out there. Try SourceTree. It's a good one, but not open source. It's free as in beer, which some people hate.

It is a clone / extension of Confluence.
Could be useful as Atlassian stuffed up Confluence big time with the v4 release where they killed wiki markup and replaced it with a WYSIWYG editor.

It is a clone / extension of Confluence.
Could be useful as Atlassian stuffed up Confluence big time with the v4 release where they killed wiki markup and replaced it with a WYSIWYG editor.

It is a clone / extension of Confluence.
Could be useful as Atlassian stuffed up Confluence big time with the v4 release where they killed wiki markup and replaced it with a WYSIWYG editor.

Try to play with the Atlassian product line databases. Makes Drupal look like a cakewalk.

However, the whole idea is to avoid direct database access. That's a good security best practice anyway.

In Joomla, I am forced to directly interact with the DB (in the installer). Maybe 3.0 is different, but I have finally been able to farm off the Joomla plugin to someone who is a lot more familiar with (and likes) Joomla.

Gojira?

Yes they do. It's here: https://www.atlassian.com/software/stash/overview/

conduct code reviews here is a good tool http://www.atlassian.com/software/crucible/overview , although it is not necessary to use a tool.

Yeah, as Palestrina notes, the AOO project provides the raw numbers for actual downloads. You can even get the source for generating the numbers: https://fisheye6.atlassian.com/browse/ooo/devtools/aoo-stats Apples to apples is difficult to get to. I mean, seriously: of all those LO's bundled with linux distros, how many are being actively used? It's like getting a copy of IE with a Windows build. Aren't most cool /. people the type who use perl and pipes instead of spreadsheets anyway? 8->

How about JIRA? Used by Enterprises all over the place. You can get it OnDemand from Atlassian for $10 (which is actually just a donation to Room to Read). Check out http://www.atlassian.com/software/jira/overview

Everyone is getting in on the kinetic game these days. There was a cool demo of using kinetic to control your agile wallboard at the Atlassian Summit last month, with special guest star of Darth Vader... There is a neat open source project around using the kinetic and you dont need an xbox to play... you can control it via Ubuntu and Mac OSX. https://labs.atlassian.com/wiki/display/KINECT/Interactive+Wallboards+-+Quickstart+Guide Thank you.

I agree, God help you.
This takes a major adjustment in your thought process'. From now on it is not your job to do things. It is your job to make sure everyone else can do their jobs.
Secondly get a bug tracker, or job tracking software setup as soon as possible. (I use Jira http://www.atlassian.com/ but it is rather expensive.) If the request is not in Jira (Or whatever you chose.) then you do not do the job.

One SA to another: Good luck!

I registered here just to post this
Few years ago I was looking for a wiki solution for work. I tried Confluence, Socialtext, Dokuwiki, Twiki, Mediawiki and Deki. My findings through all that discovery was this:

Best user inferface and ease of use goes to Confluence, Socialtext and Deki.

The stupid obnoxious sales people from Socialtext and Deki quickly made me put them on the no go list. Confluence on the other hand was way better, I was not contacted by a sales person but by a friendly technician who just asked how my trial was going, if I had run into any problems she could help with and where to get support.

Twiki was amazing feature wise and the huge community behind it but it lacked polish and friendlyness. Also it was a pain to set up, documentation was of typical open sourceness, lots of detailed info but also lots of gaps.

I liked Mediawiki mainly for two reasons, very familiar interface for Wikipedia users and since Wikipedia runs mediawiki the support for Mediawiki would never ever die for as long as Wikipedia will be running (highly doubt they will migrate away). It lacked two things, propper LDAP support and access controls.

Dokuwiki was nice but nothing special, loved the fact that its file based.

When it came to presenting it to the rest of the company I had two options, choose Confluence or Mediawiki, I did not choose Twiki simply because it would have required too much time learning and customizing to please everyone. So I choose Confluence for its ease of use, feature sets and support and I choose Mediawiki for its familiarity to most (people hardly knew what a wiki was unless I added "its just like Wikipedia") and it was open source and free.

Convincing people that we needed a documentation system that was not built on word documents, text files, excel sheets and basicly whatever each person liked personaly was a pain in the ass. To get anyone else pumped up was impossible so I just stopped trying.

Instead I opted of installing Mediawiki (free) and just started using it myself. Slowly I managed to convince the few people in my department (network/system administration) to use it. I was still the biggest contributor but it became normal that the wiki was the first place to look when we had to search for documentation. After I added a what you see what you get editor it become even better to use.

Now, today, this year, I have switched to Confluence since they offer a 10 user package for $10, perfect to replace the Mediawiki setup. They even have a "universal" wiki converter to convert the old Mediawiki installation into Confluence, and I say "universal" since its just one way, from all major wikis into Confluence. I also added Gliffy for $10 for 10 users, no need for Visio anymore :)

The support for Confluence has been amazing, just go to http://support.atlassian.com/ and make a ticket and within 24 hours for even lowest priority tickets someone is there to help you. Best support by far I have received.

Confluence documentation is excellent and very detailed and about open source, Confluence is in a way open source, when you buy it you get the sourcecode as well which you are free to modify as you wish but you are not free to release it.

We also bought a 10 pack of Jira and the integration between Confluence and Jira is very nice.

The next step is convincing the rest of they company that they need this. Should be easy now after I have prooved that a wiki is a very powerful tool for documenting :)

To end this I just want to point out that when selecting a software solution you must take into account every aspect of having it around. How much it costs to start with, how much time you have to spend getting it to run, how it is to use it from the user perspective, how it is to use it form an administration perspective and if all fails, where do you get help. Open source is good in general, but for companies running open source software can be more costly than other solutions in the long run.

Before being a jackass, why don't you read the product's specs:

Requirements Gathering
A requirements specification is never complete. It is an iterative document showing only a team's intentions at a given point in time. Confluence gives development teams the flexibility to rapidly update specs and keep everyone updated as requirements change.

http://www.atlassian.com/software/confluence/tour/documentation-software.jsp

It was made for requirements, amongst other things. I didn't have the luxury of picking the tool and besides, except for Doors, I found no requirement management tool which answers all of our requirements neatly.

Ah, I get it - I finally clicked on the first link, which goes straight to...an article written by one Mr. Roblimo. That article has a few more links (actually, apart from that one, the only other links are to Atlassian and Bitbucket). If I were a cynical type of chap, I'd suggest he's trying to pump up traffic to his page on this website and being too lazy to do it well.

Yea I don't know what is going on today but the quality of many of these summaries has been awful. This one tops it off with numerous mistakes in the title alone.

I'm also not sure what Roblimo's problem with Atlassian or proprietary software is; from my experience Atlassian produces fairly good software and charges far less than competitors.

Also, how about linking to the actual press release or a news story that contains more than commentary?

I think you are missing an element. Black boxes as you say should be more reliable and have less bugs and security issues than code written by a random programmer. Take for example Hibernate. It is used by probably more than a 100,000 apps/websites. Only really obscure bugs are going to go unnoticed. Writing all your SQL by hand however is only used by one application and there is a greater potential for bugs/security issues to exist.

But this illustrates my point exactly. Of those 100,000 apps/websites that use Hibernate, how many of the developers have looked at or understood the code at all? Are you familiar with the Unresolved Major bugs with the currently released versions of just the Hibernate Core? I doubt it, given that there are presently 792 of them. (You'll have to configure the search yourself.)

My concern is that developers are blindly using such platforms because everyone else is, or they look cool, or they are fun, or they are told to, and they are either too lazy, too busy, or too trusting in the developers who wrote them to expend the effort to understand the tools that they use.

The intent of my post was not to say that we should all go about reinventing the wheel. You're right; if you do that, you end up with alot of square wheels. But we need to understand how our tools work, when we are building things that our society increasingly relies on for daily functionality. "Me bang keyboard and mouse together, make program!" is not an appropriate development strategy.

There are number of people posting comments about how this isn't an issue since Apache's code is open. Let me outline a few possible issues even with the code being ...

1. If Apache keeps non-released security information in their bug tracker it could end up being disclosed. Great if you want to get your hands on security issues before patches are released.
2. Private comments can be leaked out which are probably not meant for general consumption. Probably not a huge issue, but it depends on the content.
3. Many people use the same passwords everywhere -- and the same usernames. Any cracked accounts could prove quite useful.


On the flip side it goes to show that XSS and CSRF are, as many security (open and closed) groups note, are a major problem -- and are pretty easy to exploit. While it is not fun to have this occur it may wake up some engineers into seeing that 'if it can happen to Apache maybe we should take it seriously'.

Then there is the whole thing of Apache using Jira instead of something Open ... http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html ... :-)

Oh man. This, a day after Atlassian itself got breached:
http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html

Their fault or not, having their name linked to two breaches in as many days has gotta be unpleasant at best for Atlassian.

Working at a small startup, around 40 employees. Dev team is now up to 4 people. We use Atlassian's Jira and Confluence. Their recent price structure changes make them very affordable for small teams. Check them out. http://www.atlassian.com/

Jira. Not free, but they are running a deal for 10 user licenses for $10.

I've used trac and Bugzilla. Jira is far better than both.

Corporate support for companies who don't want to maintain their own support team. E.g. here's Atlassian's (creators of JIRA & Confluence mentioned above).

+1 for Redmine. I've been using it for about a month and so far so good.

It has a nice set of functionality: wiki, forum, time tracking, source code version control integration, etc. Interestingly, Redmine.org uses it both as a CMS for their website and for task/bug tracking for the development of Redmine itself. So it's good dogfood.

It's actually a Rails-based app, so it's easy to install and set up from any webhost that supports Rails (as many do), or you can run it internally. Rails should also help on the extensibility front, in theory.

Configurability is good and it's easy to search and create links between different issues. One limitation of Redmine is that projects can only be nested one level deep (project -> subproject) -- also a limitation of JIRA, btw. This could blessing though, as a deeply nested project tree could become hard to manage. Keeping things relatively flat and using tags/categories might be a better approach. Redmine does support tagging and categories, though I've not explored it.

You might want to take a look at JIRA.

http://www.atlassian.com/software/jira/

It is a powerful issue tracker and as long as you can live with the 10 user "starter" limit it is very cheap (10 USD).

I am in a similar situation (IT 4 persons out of 100) and JIRA has been a lifesaver.